AD-A 126 -556  DOD  PROTOCOL  REFERENCE  MODEL (U)  SYSTEM  DEVELOPMENT  CORP 
SANTA  MONICA  CA  30  SEP  82  SOC- TM- 7 172/201/01 
DCA 1 00 - 82 -C - 0036 

UNCLASSIFIED  F/G  17/2 


MICROCOPY  Rt  SOLUTION  1 1 ST  CHART 


E  file-cow. - ®M26596 


System  Oevetooment  Corporation 

2500  Cororaoo  Avenue  Santa  Monica  CA  90406  Telephone  1 2 !  3 1  820-41 1 1 


sene* 


I 

I 

I 


a  working  paper 


Base  no  vot.  rerssue 

7172/201/01 


author 

Sycek.  Staff 

technical  1 1  j.  //n. 

Richard  L.  Mandell 
release 

Gerala  A.  Cole 


This  document  v.a*prooucec  By  Contract  DCA1Q0- 

System  Oevetooment  Corporation  m  performance  of  — g~2  C~'^(j35 - 


*0  r 

Charles  A.  Savant 

date 

9/30/ 32 


DCEC  PROTOCOL  STANDARDIZATION  PROGRAM 
DoD  PROTOCOL  REFERENCE  MODEL 
SEPTEMBER  1982 


This  document  was  produced  under  subcontract  to  SDC  oy 
Gregory  3.  Ennis,  David  J.  Kaufman,  and  Kenneth  2.  31ba 
of  Sytek,  Inc. 


VISI  ruBUTiUIf  ST  A 


ApnmreH  ter  public 

^•'-h’ltion  Unlimited 


04 


09® 


,  SECURITY  CLASSIFICATION  of  this  PAGE  fH7i«n  Pala^Enlar.d; 

I  REPORT  DOCUMENTATION  PAGE 


I  REPORT  NUMBER 

7172/201/01 

4.  TITLE  (and  Subtitle) 

DoD  Protocol  Reference  Model 


jit. p  READ  INSTRUCTIONS 

MVJt- _ BEFORE  COMPLETING  FORM 

l.  GOVT  ACCESSION  HO-.  "T  RECIPIENT'S  CATALOG  NUMBER 


H24 


S  TYPE  OF  REPORT  ft  PERIOD  COVERED 


interim  technical  report 

6.  PERFORMING  ORG.  REPORT  NUMBER 


I  7  AuTHOR(a) 


B  CONTRACT  OR  GRANT  NlJMBERfsJ 


Sytek  Staff 


DCA100-82-C-0036 


9  PERFORMING  ORGANIZATION  NAME  AND  ADDRESS 

System  Development  Corporation 
2500  Colorado  Ave. 

Santa  Monica,  CA  90406 

II.  CONTROLLING  OFFICE  NAME  and  ADDRESS 

Defense  Communications  Engineering  Center 
Switched  Networks  Engineering  Directorate 
1860  Wiehle  Ave.,  Reston,  VA  22090 


to.  PROGRAM  ELEMENT  PROJECT  TASK 
AREA  4  WORK  UNIT  NUMBERS 


P.E.  33126K 
Task  1053.558 

12.  REPORT  OATE 

_ 30.  -Sep  -82 _ _ 

13  NUMBER  OF  PAGES 
68 


14  MONITORING  AGENCY  NAME  5  ADDRESSfff  different  from  Controlling  Office)  I  15.  SECURITY  CLASS,  {of  fhi*  report) 


Unclassified 


15*.  DECLASSIFICATION  DOWNGRADING 
SCHEDULE 


16  DISTRIBUTION  STATEMENT  (of  this  Report) 


Approved  for  Public  release;  distribution  unlimited 


"a.  For 


17.  DISTRIBUTION  STATEMENT  (of  fhe  abstract  entered  in  Block  20,  11  different  from  Report; 


10  SUPPLEMENTARY  NOTES 


This  document  represents  results  of  interim  studies  which  are  continuing 
at  the  DCEC  of  OCA.  A 


./or 


1  19  KEY  WORDS  fContfnu#  on  reverse  side  it  necensery  and  tdenttl v  bv  block  number) 


Protocols,  Data  Communications,  Data  Networks,  Protocol  Standardization,.''" 
Protocol  Reference  Model  •  *  \ %  » 


I  20  ABSTRACT  ( C ontlnue  on  reverse  side  (f  necessary  and  Identity  by  block  number) 


This  document  is  proposed  as  a  baseline  Reference  Model  serving  the  development 
of  standard  protocols  for  the  Department  of  Defense.  As  such,  it  attempts  to 
describe  the  design  principle:  which  are  implicit  in  the  protocols  developed 
under  the  ARPANET  and  internet  programs;  it  also  attempts  to  prescribe 
principles  for  the  development  of  future  protocols  under  the  ongoing  DoD 
Protocol  Standardization  Program  managed  by  the  Defense  Communications  Agency. 


DD  1  J  An*73  1473  eon.--  IF  I  NOV  «s  IS  OBSOLETE 


UNCLASSIFIED 


security  CLASSIFICATION  of  Th|F  page  |-l*1n-n  Data  Enlaratf) 


CONTENTS 


1.  INTRODUCTION . 1 

2.  DESCRIPTION  OF  APPROACH .  I* 

2.1  OoO  Networking  Requirements . 4 

2.2  The  DoO  Program  of  Protocol  Standardi zat i on .  6 

2.3  Relationship  with  the  ISO  Model .  7 

3.  BASIC  CONCEPTS  Of  THE  MODEL .  12 

3.1  Networks,  Hosts,  and  Processes .  12 

3.2  The  Internet . 13 

3.3  Entities  and  Protocols .  14 

3.4  Services  and  Service-Access-Po i nts . 15 

3.5  Connections  and  Connectionless  Service .  16 

3.6  Layers .  17 

4.  CURRENT  PROTOCOLS  AND  THE  SASIC  MODEL  CONCEPTS .  19 

4 .  I  Layer  i  ng . 19 

4.2  Service-Access-Points .  20 

4.3  Connections  and  Connec t i on-Endpo i nt- 1  dent i f i er s .  20 

5.  THE  PRESENTATION  LAYER .  22 

5.1  Differences  between  DoO  and  ISO  Presentation  Layers .  22 

5.2  THE  OoO  PRESENTATION  LAYER .  25 

5.3  Current  OoO  Presentation  Protocols .  27 

6.  THE  SESSION  LAYER .  28 

6.1  Differences  between  OoO  and  ISO  Session  Layer .  28 

6.2  THE  OoO  SESSION  LAYER .  31 

6.3  Current  DoO  Session  Protocols . . . 

7.  THE  TRANSPORT  LAYER .  37 

7.1  Differences  between  DoO  and  ISO  Transport  Layer .  37 

7.2  THE  DoO  TRANSPORT  LAYER .  38 

7.3  Current  OoO  Transport  Protocols .  45 

8.  THE  INTERNET  LAYER .  46 

8.1  Differences  between  OoO  and  ISO  Internet  Layer .  46 

8.2  THE  DoO  INTERNET  LAYER .  47 

8.3  Current  OoO  Internet  Protocols .  54 

9.  THE  NETWORK  LAYER .  55 

9.1  Differences  between  OoO  and  ISO  Network  Layer .  55 

9.2  THE  OoO  NETWORK  LAYER - .' .  56 

9-3  Current  OoO  Network  Layer  Protocols .  62 

10.  THE  DATA  LINK  LAYER .  63 

10.1  Differences  between  the  OoO  and  ISO  Data  Link  Layers .  63 

10.2  THE  OoO  DATA  LINK  LAYER .  64 

10.3  Current  OoO  Data  Link  Protocols .  67 


30  September  1 982 


1 


System  Development  Corporation 
TM-7172/201/01 


1 .  INTRODUCTION 

As  in  any  engineering  discipline,  the  development  of  computer  communications 
systems  is  facilitated  by  the  use  of  design  principles.  These  principles  give 
guidance  on  "good  engineering  practice"  within  the  discipline  of  computer  net¬ 
work  design. 

Fundamental  to  the  design  of  any  computer  communication  system  are  the  rules 
by  which  information  is  exchanged.  Such  rules  are  embodied  in  the  protoco I s 
which  must  be  followed  if  communication  across  a  given  network  is  to  succeed.^ 
The  discipline  of  protocol  design  has  its  own  set  of  guiding  principles  for 
"good  engineering  practice";  these  principles  have  been  found  by  experience  to 
yield  better  network  designs  if  followed.  For  example,  experience  has  taught 
that  if  the  set  of  protocols  used  within  a  network  have  a  certain  hierarchical 
structure,  then  the  overall  network  will  be  easier  to  design,  easier  to 
modify,  and  easier  to  understand.  Such  principles  have  often  gone  unstated, 
but  their  existence  and  their  utilization  have  allowed  network  design  to  move 
beyond  the  black-art  stage.- 

A  Protoco I  Reference  Mode  1  is  a  document  which  presents  principles  of  protocol 
design.  Such  a  document  may  be  "descriptive"  in  that  it  describes  the  princi¬ 
ples  which  were  indeed  followed  within  a  particular  design  effort;  it  may  be 
"prescriptive"  in  that  it  prescribes  ru I es-of-thumb  for  future  protocol 
designers. 

A  Reference  Model  document  serving  a  particular  network  design  effort  will  in 
fact  be  both  descriptive  and  prescriptive.  The  development  of  a  set  of  proto¬ 
cols  is  an  evolutionary  process,  and  successful  protocols  have  a  long  life- 
cycle.  Consequently,  the  design  of  new  protbcols  must  always  take  into  con¬ 
sideration  the  existing  environment  of  older  protocols,  and  should  be  cog¬ 
nizant  of  the  principles  that  went  into  their  design.  This  is  the  benefit  of 
a  descriptive  Reference  Model  as  new  protocols  are  developed.  The  prescrip¬ 
tive  aspects  of  a  Reference  Model  can  then  evolve,  drawing  upon  the  experience 
and  insights  gained  as  new  protocols  are  introduced  into  the  system. 

,  This  document  is  proposed  as  a  baseline  Reference  Model  serving  the  develop¬ 
ment  of  standard  protocols  for  the  Department  of  Defense.  As  such,  it 
attempts  to  describe  the  design  principles  which  are  implicit  in  the  protocols 
developed  under  the  ARPANET  and  Internet  programs;  it  also  attempts  to 
prescribe  principles  for  the  development  of  future  protocols  under  the  ongoing 
DoO  Protocol  Standard i zat i on  Program  managed  by  the  Defense  Communications 
Agency . 

The  most  well-known  protocol  Reference  Model  is  the  Reference  Model  for  Open 
Systems  Interconnection,  developed  by  ISO  [1].  This  ISC  document  is  the 
Reference  Model  being  used  within  the  international  effort  which  is  heading 
towards  a  set  of  standard  protocols  for  commercial  systems.  As  such,  it 
presents  the  design  principles  which  are  being  aoplied  as  these  new  protocols 
are  defined.  Since  the  ISO  committees  are  still  in  the  early  stages  of  this 
protocol  design  effort,  the  ISO  Model  is  at  present  mostly  prescr i pt i ve;  we 
can  anticipate  changes  in  the  ISO  document  as  the  new  protocols  are  imple¬ 
mented  and  tested. 
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The  ISO  Reference  Model  is  commonly  referred  to  as  "the"  Reference  Model. 
However,  it  can  no  longer  be  viewed  as  the  embodiment  of  universal  principles 
appropriate  for  all  network  design  efforts.  The  ISO  Model  originates  from  a 
particular  protocol  development  effort  -  admittedly  one  with  wide  scope.  The 
often-misunderstood  goal  of  the  developers  is  a  set  of  protocols  which  can  be 
implemented  by  computer  system  vendors  to  allow  communication  across 
commercially-provided  networks.  As  a  potential  user  of  commercial  systems  and 
commercial  networks,  DoD  is  clearly  interested  in  the  ISO  effort.  However, 
DoO  cannot  use  the  ISO  Model  as  a  description  of  design  principles  appropriate 
for  the  development  of  standard  protocols  within  the  military  environment. 

The  reasons  for  the  divergence  of  the  DoD  and  ISO  Reference  Models  fall  into 
two  categories: 

1.  DoD-specific  communications  requirements  (such  as  security  and  surviva¬ 
bility  requ i rements)  have  a  major  impact  on  the  shape  of  the  most 
appropriate  protocol  architecture.  These  concerns  have  not  been  upper¬ 
most  in  the  minds  of  the  ISO  developers,  and  predictably  are  not 
reflected  in  the  ISO  Model. 

2.  The  fundamental  principles  embodied  in  the  ISO  Model  are  felt  to  place 
far  too  many  restrictions  on  the  designer  of  DoO-standard  protocols. 

These  differences  will  be  explored  ii.  detail  throughout  this  document. 

One  of  the  primary  roles  of  a  Reference  Model  document  is  as  an  aid  to  the 
understanding  of  an  ongoing  network  development  effort.  The  present  document 
should  communicate  the  basic  principles  of  the  "DoD  approach  to  protocol 
design"  not  just  to  those  actively  involved  in  the  DoD  Standardization  Pro¬ 
gram,  but  also  to  those  or  the  outside  of  this  effort.  The  near-ubiquity  of 
the  ISO  document  and  the  language  it  has  popularized  means  that  this  goal  can 
best  be  achieved  by  using  elements  of  the  ISO  language  when  possible.  It 
must,  however,  be  recognized  that  the  implications  of  some  important  concepts 
(such  as  the  concept  of  a  protocol  residing  in  a  given  layer)  differ  greatly 
between  the  two  documents.  Of  course,  both  documents  to  some  extent  share 
common  concepts;  much  of  the  original  ARPANET  work  has  found  its  way  into  the 
ISO  effort.  Thus  ther *  ,s  a  certain  commonality  of  language  which  should  help 
those  familiar  with  the  ISO  model  in  their  reading  of  the  present  document. 

The  document  presented  here  is  proposed  as  a  guide  to  the  basic  direction  of 
DoD  protocol  specification  efforts.  Section  2  describes  the  basic  approach 
taken  in  the  development  of  <.ne  model.  The  role  of  the  model  in  the  overall 
DoO  protocol  s tandard i zai 1  on  effort  is  described,  and  the  relationship  between 
the  DoO  and  ISO  models  is  discussed.  Section  3  presents  the  basic  concepts 
used  in  the  model.  A  discussion  of  how  mechanisms  within  wurrent  DoD  proto¬ 
cols  relate  to  these  basic  concepts  is  presented  in  Section  U. 

Beginning  with  Section  5-  the  layers  of  the  DoD  Reference  Model  are  presented. 
Each  layer  is  first  discussed  informally,  outlining  the  deficiencies  of  the 
correspond i ng  ISO  layer  from  the  DoD  perspective.  A  "formal"  description  of 
tne  layer  is  then  given,  in  the  style  of  the  ISO  document.  This  description 
should  make  explicit  the  differences  between  the  DoD  model  and  the  ISO 
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2.  DESCRIPTION  Of  APPROACH 

The  next  sections  discuss  three  sets  of  issues  which  determine  the  shape  of 
the  DoD  Protocol  Reference  Model.  First  we  identify  certain  DoD-specific  net¬ 
working  requirements,  paying  particular  attention  to  how  such  requirements  may 
affect  a  Reference  Model.  Secondly,  the  role  of  such  a  model  within  the 
overall  DoD  program  of  protocol  standardization  is  discussed  -  the  view  of  the 
model's  developers  on  this  subject  obviously  affects  the  proper  interpretation 
of  the  model's  contents.  Finally,  the  similarities  and  differences  between 
the  OoD  and  ISO  Models  are  briefly  described. 

2 . 1  DoD  Networking  Requirements 

To  a  large  extent,  DoD ' s  needs  are  similar  to  those  of  many  other  users  of 
computer  networks.  However,  DoD's  requirements  in  some  specific  areas  demand 
the  development  of  a  DoD-specific  protocol  architecture.  The  development  of 
protocols  fcr  DoD  networks  must  take  into  consideration  the  following  DoD  con¬ 
cerns  : 


-  anticipated  DoO  network  applications 

-  internetworking  with  present  and  planned  DoD  (and  non-DoD)  systems 

-  security  requirements 

-  robustness  and  other  DoD  qual i ty-of-servi ce  issues 

-  support  of  realtime  and  tactical  communications 

-  phased  evolution  fro,.i  existing  DoD  systems  and  protocols 

The  following  paragraphs  briefly  describe  how  each  of  these  concerns  has 
affected  the  proposed  DoD  Reference  Model. 

2.1.1  Anticipated  Applications 

The  DoD  protocol  architecture  must  support  a  wide  variety  of  anticipated 
applications,  including  advanced  services  such  as  computer-based  messaging, 
multi-media  teleconferencing,  and  distributed  database  access.  Voice  applica¬ 
tions  (real-time  and  store/forward  messaging)  are  also  anticipated  to  play  a 
major  role  in  future  DoD  networking. 

The  development  of  other  network  architectures  often  proceeds  from  an  assump¬ 
tion  that  such  high-level  services  are  beyond  the  purview  of  the  basic  set  of 
standard  protocols.  Within  DoO,  however,  such  applications  can  be  explicitly 
incorporated  into  the  architecture,  and  indeed  must  be  if  true  OoD-wide  com¬ 
munication  is  to  be  possible.  Consequently,  the  DoD  Reference  Model  should 
point  towards  the  future  development  of  standard  protocols  for  such  sophisti¬ 
cated  app 1 i cat i ons . 
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2.1.2  1 nternetwork i no 

The  OoD  architecture  model  must  facilitate  the  interconnection  of  networks 
which  use  vastly  different  internal  routing  schemes,  including  broadcast-based 
local  area  networks,  long-haul  OoD  networks  such  as  DON,  demand-access  satel¬ 
lite  networks,  circuit-switched  tactical  networks,  and  X.25  public  networks, 
it  must  be  pointed  out  that  the  administrative  differences  among  such  networks 
are  often  a  greater  impediment  to  intercommunication  than  the  technological 
d i f f erences . 

Experience  has  shown  that  the  datagram  approach  typified  by  the  DARPA  Internet 
Protocol  (IP  [2])  is  capable  of  providing  the  functionality  necessary  for  such 
internetworking.  Such  an  approach  forms  the  basis  of  the  DoD  architecture's 
internetting  scheme. 

However,  some  applications  require  a  level  of  performance  which  datagram 
internetting  may  not  be  capable  of  providing.  Consequent  1 y ,  the  DoD  architec¬ 
ture  must  allow  for  alternative  internet  routing  mechanisms  which  can  support, 
for  example,  delay-sensitive  applications. 

2.1.3  Secur i ty 

DoD 1 s  security  requirements  must  be  fully  integrated  into  the  DoD  Reference 
Model.  The  architecture  includes  concepts  which  support  DoD's  security  needs, 
particularly  in  the  areas  of  data  protection,  access  control,  authentication, 
and  accountability.  The  present  Reference  Model  document  includes  explicit 
architectural  mechanisms  to  support  the  necessary  exchanges  between  "users" 
and  appropriate  access  controllers.  However,  a  full  description  of  the  secu¬ 
rity  architecture  is  not  included  here. 

2.1.4  Robustness  and  Qua  1 i ty-of -Serv i ce  Requirements 

DoD  applications  will  have  a  wide  variety  of  delay  and  reliability  require¬ 
ments.  The  model's  approach  to  such  qua  1 i ty-of -serv i ce  requirements  must  be 
integrated  coherently  throughout  the  entire  architecture.  Such  issues  ire 
present  in  all  network  architectures,  but  are  particularly  important  to  DoD 
for  crisis  management  as  well  as  for  peacetime  support  of  special  OoD  applica¬ 
tions.  Flexibility  in  the  offered  qua  1 i ty-of -serv i ce  is  important  if  voice 
and  other  "non-data"  applications  are  to  be  supported. 

Reliable  data  transm i ss i on  is  important  for  many  applications.  But  for  OoD, 
reliable  management  of  distributed  applications  is  equally  important.  Such 
requirements  are  generally  labeled  as  "survivability"  concerns.  The  architec¬ 
ture  can  support  DoO ' s  survivability  requirements  bv  providing  facilities  for 
maintaining  control  of  a  distributed  application  in  the  presence  of  node  ana 
link  failure. 

2.1.5  Support  of  Realtime  and  Tactical  Communications 

In  addition  to  their  support  of  standard  file  transfer,  messaging,  and  termi¬ 
nal  access  functions,  OoO  networks  must  often  support  realtime  traffic.  This 
includes  such  applications  as  radar  tracking  and  device  control.  Although 
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these  applications  typically  require  special i zed  transmission  techno  1 og i es ,  it 
is  critical  that  their  required  protocols  be  part  of  the  integrated  DoD  archi¬ 
tecture.  This  is  to  allow  communication  among  separately  designed  tactical 
systems  as  well  as  between  tactical  and  other  DoD  networks. 

A  key  problem  in  the  tactical  communications  arena  is  the  impact  of  very  low 
bandwidth  channels  on.  the  design  of  appropriate  protocols.  The  Reference 
Model  must  provide  guidance  to  the  designers  of  such  systems  -  allowing  use  of 
standard  protocols  whenever  possible,  and  promoting  the  coherent  inclusion  of 
tactical  systems  within  the  overall  framework  of  DoD  communications. 

2.1.6  Evolution  From  Existing  DoD  Protocols 

Finally,  the  development  of  the  DoD  architecture  must  proceed  with  an  aware¬ 
ness  that  DoD  has  a  substantia!  investment  in  current  systems  and  protocols. 
The  Reference  Model  must  describe  the  design  principles  behind  the  existing 
DoD  protocols,  particularly  IP  [2]  and  TCP  [33-  A  major  purpose  of  the  Refer¬ 
ence  Model  is  to  guide  the  evolution  of  DoD  networks  from  existing  designs  to 
a  more  complete  system  capable  of  meeting  DoD's  future  networking  needs. 

2 . 2  The  DoD  Program  of  Protocol  Standardization 

A  strong  program  of  DoD  protocol  standardization  is  required  to  effectively 
manage  the  proliferation  of  separate  DoD  communication  systems.  One  important 
piece  of  such  a  program  is  the  development  of  a  DoD  Protocol  Reference  Model. 

* 

The  Model  will  serve  to  illuminate  the  structure  of  the  set  of  protocols.  The 
desirability  for  a  new  protocol  can  emerge  from  new  user  needs  or  from  new 
technology.  Through  a  comparison  of  the  new  protocol's  informal  description 
against  the  Model  document,  proper  placement  of  the  protocol  within  the  archi¬ 
tecture  can  be  determined.  Such  an  analysis  can  also  serve  to  refine  ideas  on 
the  anticipated  protocol's  service  and  mechanisms. 

These  informal  ideas  are  made  rigorous  through  the  development  of  a  set  of 
specifications  which  together  define  the  protocol.  A  service  specification 
states  precisely  what  services  the  protocol  will  provide  to  its  users.  A 
mechanism  specification  describes  precisely  how  the  protocol  is  to  provide  its 
service  (adding  functionality  to  the  services  offered  by  the  lower  level 
protocol's).  An  interface  specification  defines  the  manner  in  which  the 
protocol's  services  may  be  invoked.  Together,  these  specification  documents 
place  the  protocol  precisely  within  the  Reference  Model,  describing  the 
interaction  between  the  new  protocol  and  other  existing  or  planned  protocols. 

During  the  detailed  development  of  the  specifications,  the  Model  document 
guides  the  protocol  designer  by  ensuring  that  the  overall  network  architecture 
is  considered.  The  designer  can  ensure  that  the  new  protocol  will  provide 
useful  services  without  redundancy.  Implementation,  validation,  and  installa¬ 
tion  of  protocol  modules  can  then  proceed  without  explicit  reference  to  the 
Reference  Model . 
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2 . 3  Relationship  with  the  ISO  Model 

The  DoO  Reference  Model  is  in  some  respects  similar  to  the  ISO  document;  in 
other  respects  there  are  significant  differences. 

2.3.1  Reasons  for  Similarities 

The  DoO  Reference  Model  must  describe  the  basic  concepts  of  network  communica¬ 
tions  as  dictated  by  DoO  requ i rements .  The  primary  "audience"  of  this 
description  consists  of  the  designers  and  users  of  networks,  protocols,  and 
systems  for  OoD  applications. 

However,  another  important  audience  consists  of  those  outside  of  the  DoD  com¬ 
munity.  It  is  often  desirable  for  DoO  to  use  commercially  available  networks 
and  networking  products  if  possible,  so  long  as  such  use  satisfies  fundamental 
DoO  requirements.  Consequently,  the  communication  of  the  DoD  approach  to  net¬ 
working  to  the  developers  of  commercial  standards  and  products  is  an  import? 
DoD  objective. 

For  this  reason,  the  present  DoO  Reference  Model  shares  much  of  the  langu 
with  the  ISO  Reference  Model  document.  The  use  of  some  common  language  fac 
i tates  comparisons  between  the  ISO  and  DoD  models,  and  it  is  hoped  that  t 
will  allow  continued  interaction  between  the  commercial  and  DoO  protocol  st 
dardization  efforts. 

DoO  use  of  commercial  network  systems  will  also  be  facilitated  if  there  is  a 
high  degree  of  correlation  between  the  services  DoD  requires  of  a  set  a  proto¬ 
cols,  and  the  services  provided  by  commercial  systems.  This  is  commonly 
stated  as  a  desire  for  "functional  equivalence"  between  different  protocols, 
and  one  of  the  goals  of  a  Reference  Model  is  to  identify  the  most  appropriate 
classification  of  protocols  according  to  the  type  of  services  they  provide. 
Although  OoD  requirements  f-or  specific  protocol  services  are  often  different 
from  those  within  the  commercial  world,  the  basic  method  of  classification 
(the  layers)  may  share  a  common  framework.  If  the  DoD  and  ISO  models  have 
such  a  common  framework,  the  idea!  of  functional  equivalence  may  be  less  unat¬ 
tainable  as  protocol  standards  based  on  the  two  models  are  developed. 

Thus  there  are  three  basic  reasons  why  the  DoD  Reference  Model  document  is 
similar  to  that  of  ISO; 

1.  The  development  of  the  ISO  model  drew  upon  many  of  the  concepts  which 
originated  in  ARPA-sponsored  research,  and  consequently  the  two  models 
share  some  common  history. 

2.  Through  the  use  of  some  common  language  ana  conceots  it  is  hoped  that  the 
communication  of  DoO  networking  approaches  to  those  familiar  with  the  ISO 
effort  i s  faci 1 i tated. 

3.  By  agreeing  in  many  instances  on  the  appropriate  division  of  functional¬ 
ity  among  layers,  the  ease  with  which  DoO  may  use  commercial  networking 
systems  may  be  enhanced. 
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The  development  of  the  DoD  Reference  Model  document  has  been  guideo  by  a 
number  of  considerations.  For  the  above  reasons,  it  is  in  many  respects  simi¬ 
lar  to  the  ISO  document.  However,  other  important  considerations  have  pre¬ 
cluded  the  wholesale  adoption  of  the  ISO  document  for  the  DoD. 

2-3-2  Reasons  for  Differences 

The  omission  of  some  DoD-specific  requirements  from  the  ISO  Model  has  already 
been  briefly  discussed,  and  will  be  touched  upon  at  various  points  further  in 
the  document.  Here  we  wish  to  make  explicit  the  fundamental  architectural 
differences  between  the  two  models. 

There  are  five  fundamental  differences: 

1.  the  meaning  of  "layer", 

2.  the  manner  in  which  one  protocol  may  use  the  services  of  another, 

3-  the  importance  of  internetworking, 

k.  the  utility  of  connectionless  services,  and 

5-  the  approach  to  management  functions. 

The  concept  of  "layer"  is  fundamental  to  the  ISO  Model.  The  concept  of  "pro¬ 
tocol  hierarchy"  is  fundamental  to  the  DoD  Model.  The  distinction  between 
these  two  concepts  has  a  major  impact  on  the  i nterpretat i on  of  the  documents 
and  on  the  actual  design  of  corresponding  protocols  and  implementations. 

The  ISO  "layer"  concept  seems  to  have  originated  in  the  following  way:  it  has 
been  found  that  we  1 1 -des i gned  computer  networks  have  their  protocols  organized 
hierarchically.  By  this  we  mean  that  one  protocol  interpreter  provides  a  com¬ 
munications  service  to  its  users  by  adding  value  to  the  services  provided  0y 
one  or  more  other  protocols;  and  "good  engineering  practice"  dictates  tnat  at 
no  point  should  one  protocol  be  implicitly  using  its  own  services,  i.e.  the 
protocols  form  a  hierarchy.  Thus  we  find  protocol  architectures  often  dep¬ 
icted  via  graphs  of  the  following  form: 


+ - >■  h - h  + - + 

|  A  |  |  5  I  |  C  | 

+ - +  -l - +  + - + 

I  /  I  I 

♦ - J - h 
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The  next  step  in  the  development  of  the  "layer"  concept  is  the  recognition 
that  in  many  respects,  protocols  in  the  same  row  of  such  a  picture  seem  to 
have  certain  features  in  common.  This  yields  the  naming  of  the  rows,  and  the 
attempt  to  describe  in  an  abstract  fashion  what  features  are  held  in  common  by 
all  protocols  within  a  given  row.  Thus  we  get  "Layers". 

There  is  no  argument  with  the  basic  thrust  of  this  exercise.  Indeed,  proto¬ 
cols  within  a  row  do  have  some  features  in  common,  the  most  important  of  which 
is  the  fact  that  they  all  use  the  services  of  protocols  further  down.  Unfor¬ 
tunately,  the  fact  that  they  use  similar  services  does  not  imply  that  they 
orov i de  similar  services.  Consequently,  any  attempt  to  rigidly  specify  the 
services  which  protocols  within  a  given  layer  provide  will  likely  exclude  cer¬ 
tain  protocols  which  in  fact  use  the  same  lower-level  services. 

This  is  the  origin  of  a  major  disagreement  between  the  ISO  and  OoD  Reference 
Models.  Within  the  ISO  Model,  the  concept  of  layer  has  become  of  paramount 
importance,  overshadowing  the  more  fundamental  notion  of  protocol  hierarchy. 
This  has  yielded  several  principles  implicit  in  the  ISO  Model,  such  as  the 
requirement  that  the  users  of  an  (N) -protocol  need  be  (N+l ) -ent i t i es .  This 
precludes  allowing  Protocol  "C"  from  using  the  services  of  Protocol  "H"  -  a 
restriction  which  does  not  arise  from  the  "arrange  protocols  hierarchically" 
maxim,  but  only  from  the  "place  protocols  in  layers"  maxim. 

Many  of  the  arguments  within  the  ISO  effort  surrounding  "minimal  layers", 
"sublayers",  and  "which  layer  does  this  belong  to"  can  be  traced  to  the  funda¬ 
mental  overemphasis  on  layers  within  the  model.  The  concept  of  layers  does  in 
fact  have  utility  as  an  explanatory  aid  -  it  is  indeed  true  that  protocols  at 
a  given  vertical  position  in  a  hierarchy  do  seem  to  have  some  features  in  com¬ 
mon.  However,  the  layers  should  not  have  a  "life  of  their  own",  dictating 
protocol  designs. 

Good  protocol  engineering  does  not  require  that  protocols  fit  into  layers;  it 
is  only  required  that  protocols  be  arranged  hierarchically.  This  latter  prin¬ 
ciple  is  the  basis  of  the  DoO  Reference  Model.  Nevertheless,  the  DoD  Refer¬ 
ence  Model  is  described  as  consisting  of  layers;  this  is  an  explanatory  tech¬ 
nique  rather  than  a  basic  principle  of  protocol  design. 

The  second  fundamental  difference  is  related  to  the  first.  Although  it  is 
possible  to  interpret  the  ISO  Model  differently,  the  following  is  a  common 
understanding  of  the  document: 

-  (N) -entities  must  exchange  data  using  services  Drovided  by  (N— 1 ) - 
ent i ties. 

-  (N-l)  entities  provide  their  service  by  exchanging  data-units  which  con¬ 
tain  (N-l)  control  information  and  data  from  the  (N) -ent i t i es . 

-  (N-l)  entities  must  be  involved  in  every  data  transfer  between  the  (N)  - 
ent i t i es , 

-  (N)  control  information  is  passed  to  the  remote  side  as  (N-l)  data. 


1 
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We  want  to  make  it  clear  that  within  the  OoD  architecture,  communication  need 
not  be  so  restricted.  In  particular,  the  DoD  Reference  Model  in  no  way  pre¬ 
cludes  the  provision  of  services  to  higher  !e'  1  users  via  the  following  tech¬ 

niques: 

-  "Escape  characters"  which  allow  the  placement  of  control  information 
within  a  data  stream  (e.g.  Telnet  [4]).  It  is  unnatural  to  describe  such 
protocols  using  the  concept  of  "data  units"  containing  both  control  and 
higher-level  data. 

-  "Control  connection  and  data  connection",  in  which  higher-level  data  and 
control  information  may  never  share  a  "data  unit".  (Similar  to  the  File 
Transfer  Protocol  [5])  • 

-  "Using  (N-l)  control  to  signal  (N)  control"  -  example:  closing  a  TCP  con¬ 
nection  implicitly  terminates  a  Telnet  connection,  without  requiring  that 
Telnet  control  information  be  passed  as  TCP  data  to  indicate  that  the 
Telnet  connection  is  to  be  closed. 

-  "Getting  out  of  the  way"  -  a  protocol  interpreter  may  be  involved  at  the 
start  of  a  sequence  of  data  transfers  (e.g.  a  name  service  protocol),  but 
need  not  "touch"  the  data  during  the  remaining  transfers. 

In  fairness  it  should  be  pointed  out  that  the  ISO  Model  may  not  in  fact  pre¬ 
clude  any  '  of  the  above  ways  in  which  a  protocol  provides  services  to  users. 
However,  the  language  of  the  ISO  Model  seems  to  be  patterned  on  a  paradigm  of 
"encapsulation"  as  the  primary  means  by  which  higher  level  control  information 
is  handled  by  the  lower  level  protocol.  The  more  fundamental  notion  is  this: 
a  protocol  provides  a  set  of  services  to  its  users,  and  the  users  may  make  any 
use  they  wish  of  these  services. 

The  third  fundamental  difference  between  the  ISO  and  DoD  Models  is  the  rela¬ 
tive  importance  given  to  the  problems  of  internetworking.  This  is  most  easily 
seen  by  considering  that  the  DoD  Reference  Model  has  explicitly  identified  an 
"Internet  Layer". 

It  is  clear  that  the  ISO  Model  cid  not  originally  place  the  proper  emphasis  on 
the  problem  of  multiple  network  routing.  Although  many  efforts  based  on  the 
ISO  work  are  now  taking  the  Network  Layer  to  include  an  Internet  Sublayer, 
this  seems  to  confuse  rather  than  clarify  the  issue  (since  it  raises  questions 
as  to  the  meaning  of  sublayers)  .  Since  in  practice  the  implementation  of  the 
internet  protocols  will  likely  be  provided  by  a  different  vendor/deve 1 oper 
from  the  implementation  of  the  subnetwork  protocols,  it  seems  that  this  con¬ 
cept  deserves  its  own  layer. 

It  is  also  difficult  to  correctly  present  the  DoD’  approach  to  internetting 
within  the  confines  of  the  ISO  Model  due  to  the  ISO  Model's  lack  of  emphasis 
on  "connectionless"  services.  This  is  the  fourth  of  the  fundamental  differ¬ 
ences  between  the  two  models. 

The  primary  use  of  connectionless  service  within  the  DoD  architecture  is  for 
internetting  -  IP  being  the  paradigm.  However,  connectionless  services  are  of 
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great  utility  in  other  contexts  as  well.  For  example,  interactions  with  a 
Name  Server  may  involve  the  use  of  a  protocol  similar  to  the  "User  Datagram 
Protocol"  (LTD P  [6]),  which  allows  exchanges  of  data  between  processes  without 
Lhe  establishment  of  a  connection.  Similarly,  many  local  networks  operate  on 
a  connectionless  basis.  The  DoD  Reference  Model  explicitly  identifies  connec¬ 
tionless  services  as  equal  in  importance  to  connection-oriented  service 
throughout  the  architecture. 

The  final  fundamental  difference  between  the  ISO  and  the  DoD  Models  is  the 
manner  in  which  various  management-related  functions  are  treated.  Here  we 
refer  to  functions  such  a.'  the  naming  of  resources,  the  control  of  access  to 
resources,  and  the  accounting  for  resource  and  network  usage.  The  ISO  Model 
has  difficulty  treating  these,  due  in  part  to  its  architectural  restrictions. 
For  example,  many  of  these  functions  are  most  naturally  handled  via  connec¬ 
tionless  services;  they  typically  involve  entities  which  are  only  involved  at 
the  initiation  or  termination  of  a  sequence  of  data  transfers;  and  many  com¬ 
municants  may  be  involved  besides  the  "users".  It  is  clear  that  protocols 
must  be  defined:  how  are  such  protocols  to  be  placed  within  the  rigid  layers 
of  the  ISO  Model? 

Given  the  DoD  Model's  less  restrictive  approach  to  "layers",  it  is  possible  to 
describe  a  uniform  approacn  to  many  of  these  system-management  protocols.  The 
DoD  Model  identifies  such  protocols  as  typical  of  "session  layer"  services, 
which  involve  the  coordinated  action  of  multiple  entities  (e.g.  access  con¬ 
trollers  or  name  servers)  on  behalf  of  users  and  administrators,  helping  to 
establish  and  manage  user  communications.  Such  protocols  are  placed  within 
the  session  layer  by  virtue  of  their  use  of  "transport  layer"  services  (e.g. 
UDP)  and  their  common  features. 

It  is  important  to  recognize  that  this  does  not  imply  that  all  data  transfers 
between  application  programs  require  handling  by  some  session  layer  protocol; 
such  an  implication  would  exist  with  the  ISO  session  layer.  There  is  in  fact 
little  in  common  between  the  ISO  and  DoD  session  layer  descr i pt i ons . 

Of  course,  there  will  be  many  protocols  defined  which  sit  at  other  locations 
within  the  protocol  architecture  which  may  play  a  role  in  the  management  of 
the  network  and  of  network  resources.  It  is  not  implied  that  all  such  proto¬ 
cols  are  most  appropriately  defined  as  "session"  protocols.  However,  it  does 
appear  that  many  similar  protocols  will  exist  which  can  be  described  as  per¬ 
forming  sess i on- 1 ayer  functions  within  the  DoD  Model. 

Another  reason  why  the  ISO  Model  cannot  deal  proDerly  with  such  services  is 
the  difficulty  of  developing  true  international  standards  for  e.g.  access  con¬ 
trol.  In  contrast,  the  Department  of  Defense  can  develop  such  standard  proto¬ 
cols,  and  indeed  must  if  communication  across  access  control  domains  is  to  be 
a  part  of  the  internetworking  services  provided  by  TCP  and  IP.  The  placement 
of  these  services  within  the  DoD  Reference  Model  thus  points  towards  future 
areas  for  protocol  standardization. 

These  are  the  major  differences  between  the  DoD  and  the  ISO  Reference  Models; 
additional  differences  will  arise  throughout  the  actual  text  of  the  Model. 
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3.  BASIC  CONCEPTS  OF  THE  MODEL 

The  DoD  Reference  Model  is  based  on  a  set  of  fundamental  concepts.  "Fundamen¬ 
tal"  concepts  in  any  subject  are  difficult  if  not  impossible  to  rigorously 
define,  ano  the  language  of  computer  networking  and  protocols  has  its  share  of 
hary  terms.  Mutual  understanding  of  such  a  language  is  typically  reached 
through  its  usage  rather  than  through  mastering  of  definitions.  In  this  sec¬ 
tion  we  describe  the  manner  in  which  the  language  of  these  fundamental  con¬ 
cepts  is  used  within  the  OoO  Reference  Model  document,  and  why  these  concepts 
have  shaped  the  model  into  its  present  form. 

3 • I  Networks,  Hosts,  and  Processes 

Although  much  is  made  of  the  "merging"  of  communications  and  computing,  it  is 
still  clear  that  the  distinction  exists.  Computers  play  an  ever-increasing 
role  in  the  transmission  of  information,  and  computations  often  involve  com¬ 
munications  -  but  nonetheless  it  is  generally  possible  to  identify  a  system's 
primary  role  as  one  of  computation  or  one  of  communications.  The  term  used  to 
describe  machines  whose  primary  role  is  one  of  computation  is  host ,  while  a 
set  of  equipment  which  acts  in  a  coordinated  fashion  to  allow  communications 
between  hosts  forms  a  network. 

Hosts  can  often  support  multiple  simultaneous  computational  activities,  which 
are  often  called  processes .  Each  process  "resides"  in  a  particular  host.  It 
is  communication  between  processes  which  must  in  fact  be  supported  by  the  net¬ 
work. 

These  three  concepts  have  yielded  a  fundamental  principle  in  the  DoD  Reference 
Model:  the  transfer  of  information  to  a  process  can  be  accomplishec  by  first 
getting  it  to  the  host  in  which  the  process  resides,  and  then  getting  it  to 
the  process  within  the  host.  These  two  "demultiplexing"  operations  can  be 
handled  independently.  Consequently,  a  network  need  only  be  concerned  with 
routing  information  between  hosts  -  so  long  as  the  hosts  agree  among  them¬ 
selves  on  how  information  is  to  be  directed  between  processes. 

As  will  become  clear,  this  principle  is  one  of  the  primary  influences  on  the 
basic  shape  of  the  DoD  Reference  Model.  A  network  conforming  to  the  Reference 
Model  must  be  able  to  distinguish  among  all  the  hosts  which  are  attached  to 
it,  and  to  route  information  accordingly.  Such  host  identification  is  typi¬ 
cally  implemented  as  an  "addressing  scheme"  for  the  network,  with  a  specific 
format  for  host  addresses  and  a  careful  management  of  address  assignments  to 
specific  hosts.  Using  these  addresses,  the  network  may  be  directed  to 
transfer  information  to  a  specified  host. 

It  should  be  pointed  out  that  once  a  network  deveiops  an  addressing  scheme, 
one  quickly  achieves  a  de  facto  definition  of  "host"  from  that  network’s  point 
of  view:  hosts  are  precisely  identified  with  addresses.  It  is  in  this  way 
that  one  finds  a  single  machine  can  be  two  hosts  (it  has  two  addresses),  or 
that  a  machine  which  is  seemingly  attached  to  a  network  may  in  fact  not  be  a 
host  from  the  network's  viewpoint  (it  has  no  address).  Such  anomalies  often 
lead  to  confusing  discussions  about  hosts. 
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In  much  the  same  manner,  with  the  introduction  of  host  addresses  one  achieves 
a  de  facto  definition  of  “network"  from  a  host's  point  of  view:  a  network  con¬ 
sists  of  the  communications  system  which  allows  data  exchanges  between  hosts 
sharing  a  particular  addressing  format,  with  the  administration  of  address 
assignments  under  common  management.  In  this  way  we  see  that  a  network  is  not 
to  be  identified  with  a  set  of  communications  equipment  drawing  from  a  common 
transmission  technology,  but  rather  is  to  be  identified  with  a  centrally 
administered  address  and  routing  scheme.  Thus  the  public  phone  system  is  a 
single  network,  even  though  k  wide  variety  of  transmission  technologies  are 
used  (satellites,  microwave  links,  and  digital  exchanges),  whereas  a  broadband 
cable  system  with  each  channel  separately  administered  may  be  considered  mul¬ 
tiple  networks. 

3 • 2  The  Internet 


At  the  heart  of  the  DoD  communication  problem  is  the  realization  that  no  one 
network  technology  is  adequate  for  all  of  the  needs  of  DoD  users.  Networks 
can  be  built  from  a  variety  of  technologies,  including  circuit-switched  and 
packet-switched  land  lines,  satellites,  coaxial  cable  local  networks,  and 
packet  radio.  Each  technology  has  certain  advantages  with  certain  types  of 
traffic  and  applications.  Consequently  the  proliferation  of  different  network 
technologies  will  continue  within  the  DoD  environment. 

In  addition,  OoD  consists  of  a  wide  variety  of  separate  agencies  and  services, 
each  with  their  own  mission.  This  has  yielded  a  multitude  of  separately 
administered  networks,  each  based  on  the  technologies  which  are  most  appropri¬ 
ate  for  its  particular  applications.  DoD  also  wishes  to  make  use  of  public 
networks  if  possible;  such  a  network  forms  an  additional  example  of  a 
separately  administered  network  within  the  DoD  environment. 

Although  many  DoD  applications  do  not  require  communication  beyond  hosts  on  a 
’single  network,  it  is  imperative  that  the  profusion  of  separate  networks  not 
preclude  communication  between  hosts  on  distinct  networks.  Thus  the  DoD 

Reference  Model  takes  as  one  of  its  fundamental  requirements  the  ability  to 
communicate  across  multiple  networks. 

The  approach  taken  to  internetwork  communication  is  similar  to  that  taken  to 
communication  within  a  single  network:  hosts  must  be  addressed  using  a  common 
format,  with  assignment  of  addresses  to  hosts  centrally  administered.  This  is 
accomplished  by  assigning  an  identifying  number  to  each  network  which  is  to 
participate,  so  that  hosts  may  be  uniquely  identified  via  a  network  ioentifler 
and  a  host  address  on  that  network.  The  collection  of  networks  wn i ch  have 
been  assigned  suen  an  identifying  network  number  are  collectively  referred  to 
as  the  i nternet . 

Network's  do  not  lose  their  individual  identity  by  part i c i pat i ng  in  the  inter¬ 
net.  The  network's  addressing  scheme  for  intranetwork  routing  needn't  be  dic¬ 
tated  by  the  internet's  administration.  However,  if  a  host  on  the  network  is 
to  participate  in  internet  communications,  it  must  be  capable  of  translating 
between  internet  and  intranet  address  formats. 
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Internet  routing  is  the  responsibility  of  internet  gateways .  A  gateway  is  a 
host  on  multiple  networks  -  i.e.  it  is  assigned  a  network  address  by  the 
administrations  of  those  networks  and  is  capable  of  exchanging  data  with  other 
hosts  on  those  networks.  In  addition,  a  gateway  must  implement  the  routing 
procedures  defined  by  the  internet  administration. 

The  simplest  internet  routing  mechanism  assumes  the  least  about  the  routing 
mechanisms  of  the  individual  networks.  This  "least  mechanism"  internet  scheme 
assumes  only  that  each  network  in  the  internet  is  capable  of  delivering  a  data 
unit  from  one  host  'to  another  with  some  high  probability  of  success.  The  net¬ 
work  service  assumed  here  is  often  referred  to  as  "datagram  service",  and  the 
style  of  internetting  it  leads  to  is  called  "datagram  internetting".  Gateways 
in  such  a  scheme  are  similar  to  packet  switches:  they  receive  a  datagram  from 
one  network,  and  determine  from  the  internet  address  of  its  intended  destina¬ 
tion  how  it  is  to  be  forwarded.  Each  datagram  is  handled  independently,  and 
if  a  datagram  is  lost,  duplicated,  or  damaged  within  a  network,  it  will  not  be 
recognized  by  the  internet. 

Datagram  internetting  is  the  basic  approach  taken  by  the  DoD  Reference  Model. 
It  is  embodied  in  the  DoD  standard  "Internet  Protocol"  (IP),  which  defines  a 
datagram  format  and  the  procedures  for  handling  datagrams  within  both  hosts 
and  gateways.  However,  other  internetting  schemes  are  possible,  and  are  also 
consistent  with  the  Reference  Model.  These  alternatives  may  provide  enhanced 
services  to  the  hosts  (for  example  to  provide  minimization  of  delay  variances 
between  speech  packets  traversing  the  internet),  and  may  take  advantage  of 
network  services  beyond  the  minimal  datagram  service. 

3 • 3  Entities  and  Protocols 


A  protocol  is  a  set  of  rules  describing  the  manner  in  which  an  existing  com¬ 
munication  service  can  be  used  to  achieve  information  transfers.  Within  com¬ 
puter  communication  networks,  the  interpreters  of  a  protocol  are  typically 
implemented  within  software.  One  such  interpreter  may  communicate  with 
another  according  to  the  rules  of  the  protocol,  using  a  "lower"  communication 
service  to  exchange  data  and  control  information. 

Often  a  protocol  is  defined  which  takes  an  existing  communication  service  and 
"adds  value"  to  it,  providing  an  enhanced  communication  service  to  its  users. 
In  this  way  the  concept  of  "protocol  hierarchy"  arises. 

Protocol  interpreters  -  and  the  users  of  protocols  -  are  implemented  in  dif¬ 
ferent  fashions  within  different  hardware/sof tware  environments.  In  many 
instances  one  finds  a  protocol  interpreter  implemented  as  a  "process",  in 
other  cases  it  may  be  defined  as  a  "procedure";  often  protocol  interpreters 
are  integrated  into  an  operating  system  kernel  or  are  made  to  appear  as  device 
drivers.  Protocol  interpreters  may  be  implemented  as  a  collection  of 
processes,  or  using  a  combination  of  various  implementation  techniques.  In 
all  cases,  however,  it  appears  to  the  remote  protocol  interpreters  across  the 
network  as  though  there  were  some  active  being  -  an  "entity"  -  who  responds 
correctly  to  the  rules  of  the  protocol  and  is  the  user  of  the  underlying  com¬ 
munication  resource. 
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In  many  respects,  the  term  "entity"  is  a  synonym  for  "protocol  interpreter”. 
However,  “entity"  has  the  following  connotations  which  are  not  explicit,  in  the 
term  "protocol  i nterpreter" : 

1.  An  entity  may  in  fact  be  capable  of  interpreting  multiple  protocols. 

2.  Although  entities  must  interpret  the  same  protocol  in  order  to  communi¬ 
cate,  they  need  not  be  the  same  in  other  respects. 

The  second  point  is  illustrated  in  so-called  "asymmetric"  protocols,  in  which 
the  two  entities  are  playing  different  roles  yet  common i ca t i ng  via  a  common 
protocol.  Name  service  protocols  are  an  example;  one  can  also  point  to  the 
distinction  between  a  "Host  IP  Entity"  and  a  "Gateway  IP  Entity".  The  specif¬ 
ication  of  an  entity  must  not  be  confused  with  the  specification  of  a  proto¬ 
col  . 

3 . A  Services  and  Service-Access-Poi nts 

A  protocol  is  often  defined  to  provide  an  enhancement  of  an  existing  communi¬ 
cations  service  for  the  benefit  of  some  "users".  For  example,  a  given  commun¬ 
ications  service  may  not  have  an  acceptable  error  rate,  and  a  protocol  can  be 
defined  to  decrease  the  perceived  error  rate  (e.g.  through  retransmissions). 
The  entitles  implementing  such  a  protocol  are  providing  a  service  to  their 
users,  and  an  important  part  of  the  specification  of  such  a  protocol  is  a 
specification  of  these  services. 

Typically,  a  protocol  is  defined  not  just  to  provide  services  to  a  single 
user,  but  to  provide  the  same  service  to  multiple  users.  This  requires  that 
the  user  entities  and  the  protocol  entity  agree  on  a  method  by  which  user 
entities  can  access  a  complete  set  of  services  independent  from  other  users' 
access  to  services.  This  idea  is  expressed  within  the  Reference  Model  using 
the  term  serv i ce-access-po i nt .  A  service-access-point  is  the  abstraction  used 
throughout  the  Model  for  the  means  by  which  a  user  entity  may  access  the  ser¬ 
vices  of  a  given  protocol  entity. 

A  protocol  typically  includes  a  defined  means  of  address i ng  a  service-access- 
point.  In  this  way,  user  entities  may  be  identified  within  the  protocol  by 
their  address,  i.e.  by  the  address  of  the  service-access-point  to  which  they 
are  attached.  It  should  be  pointed  out  that  although  a  specific  user  enti  ty 
may  be  attached  to  multiple  service-access-points,  this  need  not  be  known  to 
the  protocol  entity,  who  treats  all  serv i ce-access-po i n t  independently. 

It  is  definitely  not  true  that  every  entity  provides  services  to  a  set  of 
users.  For  example,  a  "routing"  entity  (such  as  a  Gateway  IP  Entity)  need  not 
have  a  "service  specification"  describing  what  services  it  offers  at  its 
service-access-points.  The  "services"  provided  by  such  an  entity  are  on 
behalf  of  remote  entities,  rather  than  on  behalf  of  a  local  "higher"  user 
entity. 
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3.5  Connections  and  Connectionless  Service 

Many  protocols  make  use  of  the  concept  of  a  "connection".  Connection-oriented 
communications  between  entities  typically  require  the  establishment  of  state 
information  within  the  entities  which  persists  (appropr i ate  1 y  updated) 
throughout  the  duration  of  the  data  transfers.  Such  state  information  is 
present,  for  example,  if  reliable  data  transfers  are  required,  and  the  para¬ 
digm  of  a  connection-oriented  service  is  the  "reliably  sequenced  and  flow  con¬ 
trolled  virtual  connection".  It  should  be  pointed  out,  however,  that 
connection-oriented  protocols  are  also  of  utility  for  other  applications  which 
may  have  specific  oelay  requirements  that  require  reservation  of  resources 
throughout  the  network. 

The  initialization  of  such  state  information  often  requires  the  exchange  of 
control  information  prior  to  the  transfer  of  any  user  data.  A  similar 
exchange  is  often  required  to  terminate  the  connection.  This  is  often 
expressed  by  describing  the  connection  as  passing  through  an  establishment 
phase,  a  data  transfer  phase,  and  a  termination  phase.  Although  data  may 
indeed  be  transf errab 1 e  in  all  phases,  such  connection-oriented  protocols 
nonetheless  have  these  distinct  phases. 

"Connectionless"  transfers,  in  contrast,  do  not  require  such  phases.  Indivi¬ 
dual  data  transfers  are  treated  independently,  with  no  state  information  main¬ 
tained  by  the  communicants  between  separate  data  transfers.  Connectionless 
service  is  often  of  great  utility  for  applications  which  cannot  tolerate  the 
overhead  of  connections,  and  which  do  not  need  the  enhanced  services  provided 
by  a  connection-oriented  protocol. 

Of  particular  importance  within  the  DoD  Reference  Mode!  is  the  use  of  connec¬ 
tionless  transfers  to  support  internetworking.  This  approach  arises  from 
several  considerations,  including: 

1.  The  variety  of  approaches  taken  within  separate  networks  for  connection- 
oriented  services  precludes  the  easy  concatenation  of  distinct  connec¬ 
tions  across  multiple  networks. 

2.  Since  the  concatenation  of  reliable  connections  does  not  necessarily 
yield  a  reliable  connection,  "end-to-end"  acknowledgments  and  retransmis¬ 
sions  are  required  to  achieve  reliability.  This  removes  the  necessity  of 
reliable  connections  across  individual  networks. 

3.  All  networks  can  support  the  independent  transfer  of  separate  packets 
from  an  entry  point  to  an  exit  point,  with  some  probability  that  packets 
may  be  lost,  duplicated,  or  otherwise  mishandled. 

U.  Some  internetwork  applications  do  not  require  reliable  connections. 

These  cons i derat i ons  argue  for  the  "datagram"  approach  to  internetting  taken 
by  the  DoD  Reference  Model . 

Connection-oriented  protocols  typically  allow  users  to  establish  multiple 
simultaneous  connections  at  a  given  service-access-point.  Such  connections 
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are  identified  via  a  "connect i on-endpoi nt- i dent i f i er" ,  which  is  a  locally  sig¬ 
nificant  identifier  used  between  the  user  entity  and  the  connec t i on-or i ented 
protocol  entity  to  name  the  connection. 

3 . 6  Layers 

The  DoD  Reference  Model  draws  upon  the  concept  of  "layers".  The  layer  conc»pt 
is  an  explanatory  technique  allowing  for  multiple  protocols  of  a  similar 
nature  to  be  described. 

Distinct  protocols  may  have  some  features  in  common.  For  example,  all  proto¬ 
cols  using  the  services  of  a  given  protocol  will  have  at  least  that  in  common: 
they  require  similar  services.  Other  protocols  may  provide  similar  services 
to  their  users,  such  as  "process- 1 evel  addressability",  or  "virtualization  of 
data  formats".  The  attempt  to  describe  the  similarities  within  such  sets  of 
protocols  can  be  a  useful  exercise. 

The  only  restriction  placed  on  protocol  architectures  by  good  engineering 
practice  is  that  they  be  hierarchically  arranged.  Protocols  which  occur  in  a 
similar  vertical  position  within  a  hierarchy  are  often  found  to  have  signifi¬ 
cant  features  in  common  beyond  their  (perhaps  coincidental)  architectural 
placement.  By  placing  protocols  in  layers,  it  is  hoped  that  some  general  com¬ 
mon  features  of  a  set  of  protocols  may  be  easily  described. 

One  of  the  major  purposes  of  the  DoD  Reference  Model  is  as  an  explanatory 
document  covering  OoO  standard  protocols.  As  an  agent  of  exposition,  the 
layer  concept  promises  to  aid  the  reader  in  his  understanding,  and  for  this 
reason  the  OoO  Reference  Mode!  is  organized  by  layers.  However,  it  must  be 
remembered  that  the  placement  of  a  protocol  within  a  specific  protocol  archi¬ 
tecture  depends  upon  the  specific  services  that  it  requires  and  the  specific 
services  that  it  provides.  Such  considerations  may  make  it  difficult  to  prop¬ 
erly  place  a  protocol  within  a  specific  layer  without  misleading  the  reader. 

Given  the  descriptive  nature  of  the  Reference-  Mode!  layers,  the  following 
principles  apply: 

1.  Each  layer  may  consist  of  multiple  protocols. 

2.  In  general,  protocols  within  a  layer  have  features  in  common  which  can  be 
described  by  describing  the  layer. 

3.  in  general,  a  protocol  in  a  layer  uses  the  services  of  protocols  in  the 
next  lower  layer,  and  provides  services  to  the  protocols  of  the  next 
h i gher  1 ayer . 

However,  the  Reference  Mode!  in  no  way  prohibits  the  direct  use  of  any 
protocol's  services  by  any  higher  layer  entity.  In  this  respect,  the  layer 
concept  is  seen  not  to  be  a  fundamental  principle  of  the  DoD  Reference  Model. 
The  fundamental  principle  is  the  arrangement  of  protocols  into  a  hierarchy; 
the  use  of  layers  allows  for  general  features  of  the  hierarchy  to  be 
descr i bed . 
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The  layers  of  the  the  DoD  Reference  Mode!  include  the  following: 

-  Presentation  Layer,  containing  protocols  which  perform  virtualization  of 
data  formats  for  specific  types  of  applications. 

-  Session  Layer,  containing  protocols  which  help  to  coordinate  the  estab¬ 
lishment  of  user  communications  through  the  mediation  of  specialized 
ent i t i es . 

-  Transport  Layer,  containing  protocols  which  provide  for  process-to- 
process  communication  across  one  or  more  networks. 

-  Internet  Layer,  containing  protocols  which  perform  routing  between  net¬ 
works  . 

-  Network  Layer,  containing  network-specific  protocols  which  allow  for  data 
transfers  across  a  single  network. 

-  Link  Layer,  containing  protocols  which  manage  the  transfer  of  data  across 
a  single  physical  channel. 

The  descriptions  of  these  layers  form  the  major  sections  of  the  DoD  Reference 
Mode  1  . 
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4.  CURRENT  PROTOCOLS  AND  THE  3AS 1 C  MODEL  CONCEPTS 

One  of  the  primary  goals  of  the  reference  model  development  effort  is  to  main¬ 
tain  archi tectural  compatibility  with  the  DoO  internetting  architecture 
(TCP/IP).  In  this  section,  we  examine  how  closely  the  fundamental'  mechanisms 
within  TCP/IP  fit  the  basic  concepts  described  in  the  previous  section. 

4. 1  Layer i nq 

The  current  OoO  protocols  are  commonly  placed  within  a  four  1 ayered-  h i erarchy : 


application  (FTP,  Telnet,  Name  Server  Protocol  ...) 


transport  (TCP,  UDP) 


internet  (IP) 


subnetwork  0822,  X  .  2  5  .  •••) 


Each  layer  has  its  "entities"  (the  various  protocol  interpreters),  and  enti¬ 
ties  within  a  layer  may  provide  services  to  entities  within  higher  layers. 


The  layering  of  the  OoO  Reference  Model  is  very  similar,  with  two  exceptions: 


1.  The  protocols  witnin  the  topmost  layer  within  the  above  diagram  have  only 
one  thing  in  common:  they  use  the  services  of  TCP  and  UDP.  The  DoD 
Reference  Model  refines  this  layer  by  recognizing  that  some  of  the  proto¬ 
cols  provide  "v i r tua I i za t i on  of  data  format"  services  (and  are  placed  in 
the  Presentation  layer),  while  others  involve  interactions  with  special¬ 
ized  entities  (such  as  name  servers  or  access  controllers)  wnich  help  to 
manage  the  data  transfers  required  by  the  Presentation  Layer  or  other 
entities.  These  other  protocols  are  placed  within  the  Session  Laver  for 
expository  purposes. 


2.  The  above  picture  does  not  refine  the  manner  in  which  subnetwork  services 
are  accessed  into  a  layered  structure.  The  DoD  Reference  hode1  includes 
a  separate  Link  Layer,  recognizing  that  such  link  protocols  00  form  an 
important  class  of  protocols,  providing  services  wnich  3re  often  auite 
distinct  from  network  protocols.  Standardization  of  such  protocols  will 
continue  to  be  an  important  OoO  concern,  and  consequently  the  DoO  Refer¬ 
ence  Model  explicitly  identifies  a  Link  Layer. 
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m . 2  Service-Access-Points 

In  the  DoD  Reference  Model,  an  (N) -entity  accesses  the  services  of  an  (N-l)- 
protocol  at  a  "serv i ce-access-po i nt" .  It  is  the  service-access-points  of  a 
protocol  which  are  assigned  "addresses",  allowing  those  (N)-entities  currently 
using  an  (N-l) -servi ce-access-poi nt  to  be  referenced  via  the  access-point's 
address . 

Similar  concepts  are  found  within  TCP  and  IP;  however,  they  don't  quite  match 
the  exact  concept  of  a  service-access-point  and  the'related  addressing  archi¬ 
tecture  of  the  Reference  Model. 

it .  2  .  1  TCP  Serv  i  ce-Access-Po  i  nts 

The  TCP  “port"  seems  to  naturally  correspond  to  the  service-access-point  con¬ 
cept.  Remote  entities  can  be  reached  by  referring  to  a  port  to  which  they  are 
currently  attached.  Multiple  connections  can  be  terminated  at  a  single  port'. 
The  binding  between  a  higher-level  entity  and  a  TCP  port  need  not  be  per¬ 
manent.  All  these  are  properties  of  service-access-points  as  well. 

However,  TCP  ports  play  an  additional  role  which  distinguishes  them  from 
service-access-points.  A  TCP  connection  is  determined  by  the  pair  of  ports  at 
the  two  ends.  It  is  not  possible  to  have  multiple  simultaneous  TCP- 
connections  between  the  same  pair  of  ports.  Thus  ports  are  used  to  identify 
connections  in  addition  to  their  role  as  access-points  for  the  TCP  service. 

This  aspect  of  TCP  ports  is  similar  to  the  concept  of  a  "connection-endpoint- 
identifier"  within  the  Reference  Model,  which  is  discussed  below.  Thus  the 
correspondence  between  TCP-port  and  service-access-point  is  not  exact. 

A.  2.2  IP  Service-Access-Points 

IP  includes  a  Protocol  Identifier  mechanism  for  distinguishing  among  multiple 
higher-level  entities.  This  shares  many  properties  with  the  concept  of  a 
service-access- point. 

The  primary  difference  between  the  "Protocol  Identifier"  and  a  true  service 
access  point  is  the  implicit  correspondence  between  the  Protocol  Identifiers 
at  the  two  ends  of  a  transfer.  Although  IP  implementations  could  perhaps 
allow  the  protocol  entity  with  identifier  5  to  exchange  datagrams  with  a  pro¬ 
tocol  entity  with  identifier  7.  such  is  not  ordinarily  the  case. 

'n  contrast,  service-access-point  addresses  need  not  have  any  relationship  at 
tne  two  ends  of  a  data  transfer. 

A • 3  Connections  and  Conncc t i on-E ndpo i nt- I  den t i f j er s 

The  ISO  Reference  Mode!  is  heavily  connection-oriented;  the  DoO  Reference 
Model  incorporates  connec t i on  1  ess  transfers  as  well.  Nonetheless,  connections 
still  play  an  important  role  in  the  DoD  Reference  Model,  and  the  key  architec¬ 
tural  concept  of  "connec t i on-endpoi nt- ident i f i er"  must  be  compared  with  simi- 
1 ar  not i ons  i n  TCP . 
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In  the  DoO  Reference  Model,  there  may  be  any  number  of  simultaneous  connec¬ 
tions  between  two  service-access-points.  These  connections  are  distinguished 
by  "connect i on-endpo i nt- i dent i f i er s"  which  have  purely  local  significance; 
i.e.  they  can  be  different  at  the  two  ends  of  the  connection. 

TCP  connections  are  between  port  pairs;  only  one  connection  may  exist  between 
a  port  pair.  Thus  connections  are  identified  at  both  ends  by  the  port  pair. 
This  differs  from  the  connec t i on-endpo i nt- i dent i f i er  concept  in  two  ways: 

1.  Port  pairs  do  not  identify  connections  in  a  manner  which  is  of  only  local 
s i gn i f i cance . 

2.  Multiple  simultaneous  connections  are  not  possible  between  the  same  port 
pair. 

The  first  item  is  relatively  insignificant,  since  additional  local  identifiers 
can  always  be  introduced.  The  second  item,  however,  is  a  major  arch i tec tur a  1 
distinction  between  TCP  and  the  OoD  Reference  Model. 
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5.  THE  PRESENTATION  LAYER 


Differences  between  DoD  and 


Presentation  layers 


The  Presentation  Layer  allows  user-entities  to  communicate  without  the  neces¬ 
sity  of  a  common  syntax.  By  providing  the  necessary  syntax  transformations 
(while  preserving  meaning),  protocols  within  the  Presentation  Layer  avoid  the 
n  x  m  problem  which  would  result  if  user-entities  needed  to  translate  the  syn¬ 
taxes  of  every  other  user-entity. 


The  primary  model  for  Presentation  Layer  operation  (at  least  implicitly) 
involves  the  concepts  of  "transfer  syntax"  and  "local  syntax".  In  this  model, 
a  presentation-entity  exchanges  data  with  its  local  user-entity  using  a  local 
syntax  which  they  agree  upon.  For  transfers  between  presentation-entities, 
data  is  represented  in  a  transfer  syntax  which  may  or  may  not  be  different 
from  the  original  local  syntax.  The  receiving  presentation-entity  passes  the 
data  to  its  user-entity  using  a  third  syntax,  local  to  that  interface. 


A  more  general  model  involves  the  notion  of  "network  virtual  resource".  Here 
the  user-entities  are  provided  with  a  local  representation  of  a  shared 
resource  (e.g.  a  terminal,  or  a  file)  which  they  can  manipulate  using 
locally-defined  access  methods.  The  presentation-entities  map  the  local 
representation's  data  structures  into  a  "standard"  (or  "virtual")  representa¬ 
tion  of  the  resource.  Modifications  made  by  an  user-entity  to  its  local 
representat i on  of  the  resource  are  communicated  between  presentation-entities 
as  cnanges  to  the  virtual  resource.  Upon  detection  of  a  change  in  the  virtual 
resource,  presentation-entities  make  appropriate  moo i f i cat i ons  to  its  user- 
entity's  local  representation. 


Actually,  the  virtual  resource  only  exists  as  "images"  of  its  current  state  as 
perceived  Oy  the  different  presentation-entities.  Since  updates  to  the  vir¬ 
tual  resource's  state  cannot  be  instantaneously  communicated  between 
presentation-entities,  some  temporary  inconsistencies  may  exist  among  the  dif¬ 
ferent  views.  Presentation  Layer  functions  must  ensure  that  such  inconsisten¬ 
cies  do  not  lead  to  deadlocks  or  permanent  data  misrepresentations. 


With  the  virtual  resource  approach,  communication  between  user-entities  occurs 
through  changes  in  the  state  of  a  data  structure  which  represents  a  shared 
resource.  User -ent i t i es  induce  and  detect  these  changes  by  accessing  their 
local  representation  of  the  shared  resource.  There  need  be  no  explicit  "con¬ 
nection"  between  user -ent i t i es  over  which  data  is  to  be  "transferred".  Of 
course,  connections  of  some  sort  might  exist  at  lower  layers  to  facilitate  the 
communication  of  resource  state  changes  between  presentation-entities.  but 
such  connections  can  be  hidden  from  the  user-entities.  The  advantage  of  such 
an  approach  is  that  multiple  user-entities  can  be  accessing  the  same  shared 
resource . 


The  ISC  P-esentat i on  Layer  includes  some  of  the  concepts  of  network  virtual 
resources.  in  particular,  the  concept  of  "presentat i on- i mage"  is  introduced 
as  the  presentation-entity's  data  structure  representing  its  local  view  of  the 
shared  resources  state.  However,  there  is  no  analogous  concept  introduced 
giving  the  user-entity's  local  data  structure  -  i.e.  there  is  no  "local 
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representat i on"  in  the  sense  used  above.  In  fact,  communication  between 
user-entities  is  couched  in  "connection-oriented"  terms.  Data  is  transferred 
over  presentation-connections,  with  "code  and  character  conversions"  performed 
in  the  Presentation  Layer. 

It  is  not  clear  in  the  ISO  Model  how  the  presentation-entities  are  to  use 
session-connections  to  provide  the  presentation-service.  It  is  stated  that 
"there  is  a  one-to-one  correspondence  between  presentat i on-serv i ce-access- 
poi nt-address  and  session-service-access-point-  address.  There  is  no  multi¬ 
plexing  in  the  Presentation  Layer".  However,  one  can  easily  invent  situations 
in  which  multiple  session-connections  are  required  to  support  a  single  data 
structure  for  user-entity  access  (for  example,  one  sess 1  on-connect i on  for 
real-time  images  with  a  second  for  the  cursor).  The  ISO  description  does  not 
make  explicit  whether  such  an  application  would  require  two  separate 
presentation-connections  (which  would  then  be  synchronized  within  the  Applica¬ 
tion  Layer).  Such  a  problem  does  not  arise  with  the  modifications  proposed 
for  the  DoD  Presentation  Layer. 

The  DoD  Presentation  Layer  explicitly  incorporates  the  concept  of  user-entity 
communication  via  manipulation  of  a  shared  resource.  .Multiple  images  of  the 
resource's  state  are  accessed  by  the  entities  involved  (local  representations 
accessed  by  user-entities,  which  are  mapped  into  the  virtual  representation  by 
the  presen ta t i on-ent i t i es) .  The  Presentation  Layer  is  responsible  for  ensur¬ 
ing  consistency  among  the  various  representations.  Tnis  is  accomplished  via 
communication  between  the  presentation-entities. 

Data  transfers  between  presentation-entities  will  in  general  use  the  services 
of  protocols  within  the  Transport  Layer.  Session  Layer  services  (e.g.  access 
control,  name  service)  may  also  be  invoked  to  support  the  management  of  the 
user  communications. 

This  approach  has  the  following  advantages  for  DoD: 

1.  It  is  more  consistent  than  the  ISO  Presentation  Layer,  in  which  user- 
entities  access  presentation-connections  (no  explicit  data  structure) 
which  are  mapped  to  presen  tat i on- i mages  (a  data  structure)  within  the 
Presentation  Layer. 

2.  Information  of  vastly  different  formats  (e.g.  the  image  and  cursor  data 
described  above)  can  easily  be  accomodated  within  the  "local  representa¬ 
tion"  data  structure  to  be  accessed  by  an  user-entity.  Such  a  situation 
is  not  easily  managed  within  the  ISO  presentation-connection  approach. 
Since  "multimedia"  services  are  anticipated  to  be  a  major  DoD  require¬ 
ment,  it  is  important  that  they  be  handled  cleanly. 

3.  The  shared  resource  can  be  accessed  by  more  than  two  user -ent i t i es .  For 
example,  a  virtual  file  service  may  be  distributed  over  multiple  nodes. 
The  distributed  nature  of  such  a  service  could  be  hidden  from  the  user 
user-entity.  Such  a  presentat i on-serv i ce  would  make  effective  use  of  the 
muiti-entity  "session"  construct  in  the  OoO  Session  Layer. 
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it.  Teleconferencing  (another  important  future  DoD  service}  requires  a 
sophisticated  Presentation  Layer.  Multiple  user-entities  must  communi¬ 
cate,  either  through  a  conference  controller  or  "directly".  Syntax  nego¬ 
tiations  ane  transformat  ions  are  complex  due  to  the  multiplicity  of  par¬ 
ticipants.  Cata  from  multiple  sources  must  be  time-multiplexed  to  the 
receiving  user-entity.  It  is  anticipated  that  sophisticated  Session 
Layer  protocols  will  be  require  to  support  such  teleconferences,  in  con¬ 
junction  with  Presentation  Layer  protocols  which  can  provide  for  multi¬ 
entity  access  to  a  single  shared  resource. 


Finally,  the  issue  of  quality  of  service  is  absent  from  the  ISO  Presentation 
Layer.  In  the  DoO  model  this  is  explicitly  addressed.  An  user-entity  can 
negotiate,  for  example,  delay  and  reliability  parameters  which  affect  the 
manner  in  which  the  presentation-entities  communicate  resource  state  informa¬ 
tion.  For  the  most  part,  these  parameters  will  be  merely  passed  down  to  the 
lower  protocols  un interpreted  by  the  presentation-entities.  However,  they  may 
affect  internal  Presentation  layer  functions  such  as  data  compression. 


In  summary, 


the  differences  between  the  DoD  and  ISO  Presentation  Layers  are: 


1.  User-entities  may  be  provided  a  d.ata  structure  which  represents  the  state 
of  a  shared  resource  in  a  syntax  appropriate  to  the  local  system. 

2.  User-entities  communicate  via  manipulations  of  their  images  of  the  shared 
resource.  The  Presentation  Layer  protocols  are  responsible  for  ensuring 
the  consistency  of  the  different  images. 

3.  Multiple  user-entities  can  sha*e  a  resource.  Such  entities  can  even 
exist  in  different  systems  -  in  this  sense  the  resource  can  be  distri¬ 
buted  . 


U.  The  data  structure  provided  by  a  presentation-entity  for  an  user -ent i ty  1  s 
locai  image  can  represent  multimedia  resources. 

3.  Quality  of  service  parameters  can  be  negotiated  to  determine  the  way  in 
which  presentation-entities  exchange  the  information  necessary  to  main¬ 
tain  consistency  across  the  multiple  images. 


The  DoO  Presentation  Layer  is  viewed  as  the  proper  location  of  a  wide  var i  ety 
of  sophisticated  services  required  for  future  DoO  communications:  virtual  ter¬ 
minal  services,  virtual  filestores,  distributed  database  access,  telecon¬ 
ferencing,  and  advanced  messaging  support.  Whereas  the  ISO  Presentation  Layer 
is  capable  of  eliminating  problems  of  syntax  distinctions  at  the  ends  of  a 
point-to-point  connection,  the  DoD  Presentation  Layer  can  handle  syntax  prob¬ 
lems  of  multi-entity  applications  -  even  hiding  the  distributed  nature  of  a 
shared  resource.  The  possibility  of  multi-entity  coordination  provided  by  the 
DoO  Session  Layer  allows  for  these  functions  to  be  placed  coherently  within 
the  DoO  Presentation  Layer. 
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5.2  THE  OoQ  PRESENTATION  LAYER 
5.2.1  Purpose 

The  purpose  of  the  protocols  within  the  Presentation  Layer  is  to  represent 
information  to  communicating  user*ent i t i es  in  a  way  that  preserves  meaning 
while  resolving  syntax  differences.  These  protocols  allow  user-entities  to 
manipulate  remote  resources  using  locally  defined  access  methods.  in  this  way 
user-entities  do  not  require  knowledge  of  how  the  resource  may  be  represented 
to  other  user-entities. 

In  the  OoO  arch i tecture,  the  syntaxes  used  by  application  processes  that  wish 
to  communicate  may  be  very  similar  or  quite  dissimilar.  When  they  are  simi¬ 
lar,  the  data  transformat i on  and  formatting  functions  may  not  be  needed  at 
all;  however,  when  they  are  dissimilar,  protocols  within  the  Presentation 
Layer  provide  the  means  to  converse  and  decide  where  needed  syntax  conversions 
will  take  place. 

User-entities  communicate  by  manipulating  a  shared  resource.  Such  manipula¬ 
tion  is  achieved  through  local  manipulation  of  the  resource's  local  represen¬ 
tation  as  provided  by  the  local  pr esentat i on-ent i ty .  It  is  the  responsibility 
of  the  Presentation  Layer  protocols  to  ensure  that  the  resource's  representa¬ 
tion  to  other  user-entities  properly  reflect  such  manipulations. 

5-2.2  Services  Provided  to  Users 


Protocols  within  the  Presentation  Layer  may  provide  the  following  services: 

a)  selection  (through  negotiation)  of  syntax  for  local  representation  of  the 
resource; 

b)  manipulation  primitives  allowing  modification  of  local  representation; 

c)  communication  of  local  changes  to  those  remote  entities  sharing  access  to 
the  resource; 

d)  access  primitives  allowing  those  changes  to  the  resource  made  by  remote 
entities  to  be  visible  to  the  local  user-entity  (i.e.  remote  changes  are 
reflected  in  the  local  representation); 

e)  selection  (through  negotiation)  of  quality  of  service  to  be  provided, 
i.e.  delay,  reliability,  and  security  requirements  for  the  data  transfers 
necessary  to  communicate  resource  modifications  among  participating 
presentation -entities. 

5.2.3  Functions  within  the  Presentation  Layer 

When  one  user-entity  modifies  a  resource,  the  Presentation  Laver  protocol  must 
ensure  that  these  modifications  are  visible  to  other  user-entities  which 
access  that  resource.  This  involves  the  transfer  of  data  between  the  ori¬ 
ginating  user-entity  and  its  local  presentation-entity,  between  presentation- 
entities,  and  between  a  second  presentation-entity  and  its  user-entity  during 
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the  resource  access.  There  are  several  syntactic  versions  of  the  data  being 
transferred:  the  syntax  used  by  the  user-entity  of  the  originator  of  the  data, 
the  syntax  used  by  the  user-entity  accessing  the  data,  and  the  syntax  used  to 
transfer  the  data  between  presentation-  entities  ("transfer  syntax").  It  is 
clearly  possible  that  any  two  or  ail  three  of  these  syntaxes  may  be  identical. 
Protocols  within  the  Presentation  Layer  contain  the  functions  necessary  to 
transform  between  the  transfer  syntax  and  each  of  the  other  two  syntaxes  as 
requ i  red . 

There  is  not- a  single  predetermined  transfer  syntax  for  all  systems  conforming 
to  the  DoD  architecture.  The  transfer  syntax  to  be  used  on  a  presentation- 
connection  is  negotiated  between  the  correspondent  presentation-entities. 
Thus,  a  presentation-entity  must  know  the  syntax  of  its  local  system  and  the 
agreed  transfer  syntax.  Only  the  transfer  syntax  needs  to  be  referred  to  in 
the  Presentation  Layer  protocols. 

A  user-entity's  local  represen ta t i on  of  a  resource  is  provided  by  its  local 
presentation-entity.  Manipulations  of  the  local  resource  representation  by 
the  user-entity  are  made  visible  to  the  remote  user-entities  via  corresponding 
changes  in  the  remote  resource  representation.  Manipulations  of  the  resource 
by  remote  user-entities  will  be  visible  to  the  presentation-entity  via  changes 
in  the  local  represen ta t i on . 

Protocols  within  this  layer  perform  the  following  functions  to  help  accomplish 
the  above  services: 

a)  establishment  of  communications  using  the  services  of  Transport  Layer 
protocols,  which  may  also  involve  invocation  of  Session  Layer  services 

b)  negotiation  of  the  transfer  syntax: 

c)  data- transformation  and  formatting; 

Syntax  negotiations  consist  of  the  dialog  between  the  presentation-entities  on 
behalf  of  the  user-entities  to  determine  the  form  that  data  will  have  while  in 
the  DoD  internetting  environment.  The  negotiations  will  determine  what 
conversions  are  needed  (if  any)  and  where  they  will  be  performed. 
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5 . 3  Current  DoD  Presentation  Protocols 

The  proposed  DoD  Presentation  Layer  is  intended  to  provide  applications  access 
to  a  "virtual  resource".  This  service  includes  not  only  the  code  and  format 
transformations  provided  by  ISO  presentation-protocols,  but  also  can  make  a 
"distributed  resource"  (e.g.  a  distributed  file  system)  appear  (if  desired)  as 
a  single  data  structure. 

No  existing  DoD  protocol  is  currently  structured  in  this  fashion  to  allow  uni¬ 
form  access  to  a  distributed  resource.  However,  Telnet  and  FTP  provide  exam- 
pie  implementations  of  the  virtual  resource  concept.  The  proposed  DoD  archi¬ 
tecture  should  allow  the  introduction  of  more  sophisticated  resource  manage¬ 
ment  techniques  required  for  multi-media  connections  (e.g.  simultaneous  image 
and  data),  teleconferencing,  and  distributed  database  access.  Such  applica¬ 
tions  may  require  multi-entity  coordination  protocols  within  the  DoD  Session 
Layer . 

The  model  followed  within  the  DoD  Presentation  Layer  involves  "images"  of  a 
data  structure  which  represent  a  local  entity's  current  view  of  that 
structure's  state.  It  is  the  responsibility  of  the  Presentation  Layer  to 
ensure  that  the  multiple  simultaneous  (distributed)  images  are  updated 
appropriately  to  prevent  serious  iong-term  inconsistencies.  For  example,  a 
presentation  protocol  may  be  introduced  which  "presents"  to  its  attached 
user-entity  a  representation  of  a  graphic  terminal  screen  with  cursor  informa¬ 
tion.  This  local  representation  would  be  in  fact  a  data  structure  updated 
appropriately  by  the  presentation-entity  in  response  state- i nformat ion 
transmitted  by  a  correspondent  presentation-entity.  The  transfers  of  such 
state- i nformat i on  between  presentation-entities  may  involve  multiple  connec¬ 
tions  provided  by  the  lower  level  protocols,  (for  example,  separate  connec¬ 
tions  for  image  and  cursor  data).  These  multiple  lower-level  connections 
would  not  be  necessarily  visible  to  the  user-entities,  who  are  merely  access¬ 
ing  a  certain  data  structure  provided  by  the  presentation-entities. 

A  wide  variety  of  possible  presentation-protocols  are  thus  envisioned  for  the 
DoO  Presentation  Layer,  supporting  the  "virtual  resource"  requirements  of  DoD 
applications.  The  mode!  described  above  is  consistent  both  with  "point-to- 
point"  presentation  services  required  for  e.g.  virtual  terminal  support,  as 
well  as  more  complex  distributed  resources  which  are  anticipated  for  the 
future  DoD  environment. 


30  September  1982 


-28- 


System  Development  Corporation 
TM-7172/201/01 


6.  THE  SESSION  LAYER 

6 . 1  Differences  between  DoO  and  ISO  Session  Laver 

The  intent  of  the  Session  Layer  is  to  help  communicating  user-entities  manage 
their  data  transfers.  The  ISO  Session  Layer  provides  services  allowing  two 
presentat i on-ent i t i es  to  establish  a  session-connection  Between  themselves.  A 
session-connection  is  mapped  onto  a  tr anspor t-connec t i on ,  but  the  state  of  a 
session-connection  can  be  maintained  even  in  the  event  of  transport-connection 
fai lure. 

The  services  provided  through  ISO  sess  i  on-connec ons  additionally  include: 

-  quarantine  service,  allowing  a  sender  to  retjts;  ’nut  certain  oata  not  be 
made  available  to  the  receiver  unt  i  '  explictly  r-, eased  dv  the  sender, 

-  interaction  management,  a’’r—ing  the  users  o*  a  sess 1  on-connect i on  to 
exchange  the  “t'jrn", 

-  expedited  data  transfer .  and 

-  syncni-on i 2a t i on  services.  allowing  presentation-entities  to  “mark" 
specific  synchron i :at i or  points  arc  reset  the  session-connection. 

Although  these  services  are  useful,  the  Session  Layer's  enhancement  of  basic 
TransDort  Layer  services  are  so  m  nor  that  it  is  hard  to  justify  their  incor¬ 
poration  in  a  separate  layer.  if  one  informally  views  the  concept  of  a  "ses¬ 
sion"  as  a  we'l-defined  perico  of  time  during  which  application-entities  coor¬ 
dinate  their  actions  (througn  communication)  to  perform  a  specific  job,  it  is 
clear  that  the  ISO  Session  Layer  is  deficient  in  several  respects. 

First,  the  session  support  services  (e.g  Quarantine  and  interaction  manage¬ 
ment)  seem  to  oe  directed  towards  reco-d-or i entea  transaction  exchanges. 
Voice  and  other  -eal-time  stream  applications  are  not  adequately  supported  by 
the  ISO  Session  Layer.  This  is  particularly  apparent  when  one  examines  the 
issue  o(  quality  of  service  negotiation  between  the  ISO  Session  Layer  and  its 
users:  there  is  no  discussion  of  this  in  the  'SO  document.  Flexible  support 

for  a  wide  variety  of  application  traffic  is  particularly  important  for  DoD . 

Secondly,  session-connections  will  on  y  support  the  coorpinared  activity  of 
two  presentat , on-en* «s .  The  coordination  of  multiple  application  entities 
communicating  amorg  tnemselves  s  left  entirely  up  to  the  highe*-  lavers. 
Since  the  ISO  document  nowhere  expllc:tly  addresses  this  issue,  we  must  assume 
that  this  is  intended  tc  be  the  use- 1 s  responsibility. 

The  DoD  Reference  Model  takes  a  completely  different  aoprcaeh  to  the  Session 
L  ver  .  There  seems  tc  be  a  class  of  protocols  which  involve  the  interaction 
between  "users"  and  one  or  more  "specialized"  entries,  particularly  prior  to 
the  es tap  I i shment  of  user-user  communication.  For  example: 

-  A  user  wishes  to  estatlish  communication  with  a  "named"  resource,  which 
reouires  interaction  w'tr  a  name  server  to  determine  the  appropriate 
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location  information. 

-  The  network  administration  wishes  to  restrict  user  access  to  certain 
resources,  and  accomplishes  this  by  forcing  every  user  connection  estab¬ 
lishment  to  be  mediated  by  an  access  controller. 

-  A  low-priority  user  is  dominating  a  particular  resource,  and  an  agent  of 
the  network  administration  must  preempt  this  user's  communication  on 
behalf  of  a  user  with  a  critical  current  need. 

-  Upon  termination  of  a  user  connection,  usage  statistics  must  be  communi¬ 
cated  to  a  network  accounting  agent. 

The  protocols  required  for  such  interactions  seem  to  require  Transport  Layer 
services  -  e.g.  UOP  or  perhaps  TCP.  In  addition,  a  variety  of  protocols 
"related"  to  those  in  the  above  examples  seem  to  follow  the  same  pattern:  for 
example,  protocols  to  register  name/address  bindings  at  a  name  server,  or  pro¬ 
tocols  to  distribute  keys  which  enforce  access  control  decisions. 

It  is  clear  that  DoD  will  develop  standard  protocols  for  such  functions.  It 
is  possible  to  conceive  of  future  protocols  which  similarly  involve  interac- 
t  1  ons  with  multiple  specialized  entities,  supporting  sophisticated  multi-user 
presentat i on- 1  eve  1  protocols  for  teleconferencing,  distributed  file  systems, 
and  other  future  DoO  applications.  The  reliable  management  of  critical  dis¬ 
tributed  applications  in  the  presence  of  node  or  link  failures  will  require 
coordinating  the  activity  of  redundant  entities.  Thus  the  important  DoO  con¬ 
cept  of  survivability  requires  that  mechanisms  for  distributed  application 
control  exist  in  the  architecture.  Such  protocols  are  considered  to  be  ses¬ 
sion  protocols  within  the  DoD  Reference  Model.  This  is  a  very  different  Ses¬ 
sion  Layer  from  that  within  the  ISO  Model. 

The  ISO  Model  does  not  explictly  address  how  such  mu  1 1 i -ent i ty/mu 1 1 i - , 
connection  applications  might  be  supported  within  the  arch i tecture .  Thus 
ISO's  is  a  "point-to-point"  architecture,  giving  the  rules  governing  communi¬ 
cation  between  two  app 1 i ca t i on-ent i t i es .  The  manner  in  which  these  two  enti¬ 
ties  may  be  participating  in  a  coordinated  action  with  other  entities  is 
irrelevant  to  the  ISO  model.  Management  of  such  multi-entity  functions  is 
placed  entirely  within  the  user  domain. 

Although  the  above  applications  are  quite  different  in  their  specific  require¬ 
ments,  the  manner  in  which  the  necessary  user-user  communications  might  be 
established,  monitored,  and  terminated  shows  some  similarities.  Typically  at 
the  time  of  session  establishment,  some  interaction  is  required  between  the 
user  entities  and  some  specialized  control  entities  (e.g.  name  servers,  access 
controllers,  or  key  generators).  Other  entit'es  may  play  an  additional  con¬ 
trolling  or  monitoring  role  during  the  session,  requiring  perhaps  the  ability 
to  query  the  status  of  the  participating  entities.  Finally,  session  termina¬ 
tion  may  again  require  interaction  with  designated  specialized  entities. 

Some  of  these  functions  are  similar  to  those  provided  by  the  ISO  Session  Layer 
for  po i n t- to-po i nt  session-connections,  e.g.  interaction  management  and 
maintenance  of  sess i on-connec t i on  state  in  the  face  of  transport-connection 
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abortions.  Use  of  multiple  transpor t -connec t i ons  between  two  session-entities 
has  already  been  incorpoated  within  the  ISO  Model. 

The  proposed  OoD  Architecture  differs  from  the  ISO  Session  Layer  in  its  con¬ 
cept  of  "session".  A  session  is  established  among  user-entities.  Session 
establishment  may  involve  interaction  with  specialized  session-entities.  Once 
established,  a  session  may  in  fact  be  identical  to  a  single  transport- 
connection  -  that  is,  the  session-entities  which  participated  in  the  estab¬ 
lishment  of  the  session  may  play  no  role  once  the  session  is  established. 
This  is  in  strong  contrast  to  the  basic  princiole  in  the  ISO  Model  that  every 
data  transfer  must  be  "touched"  by  a  session-enti  ty  • 

Some  specialized  session  entities  may  be  capable  of  forcibly  terminating  a 
user  session,  e.g.  for  security  or  precedence  reasons.  Thus  the  session  con¬ 
cept  fits  in  with  fundamental  DoO  requirements. 

A  variety  of  session  protocols  are  anticipated,  supporting  different  applica¬ 
tions  and  providing  different  management  services.  Some  session  protocols 
(e.g.  access  control  protocols)  may  be  virtually  invisible  to  the  users.  Oth¬ 
ers  (such  as  those  providing  name  service)  may  be  seen  by  the  users  as  provid¬ 
ing  substantial  additional  functionality  over  the  "raw"  transport  layer  ser- 
v  i  ces  . 

In  summary,  there  are  three  ways  in  which  the  DoD  Session  Layer  differs  from 
the  ISO  Session  Layer: 

1.  O.uality  of  service  parameters  are  explicitly  described  which  are  negoti¬ 
able  across  a  session-service-access-point,  ensuring  that  real-time  and 
other  classes  of  applications  will  be  adequately  supported  by  the  Session 
Layer  protocols. 

,  2.  Distributed  applications  are  directly  supported  through  the  "session" 
concept,  which  allows  for  the  existence  of  specialized  administrative 
entities  which  participate  in  the  establishment,  monitoring,  and  termina¬ 
tion  of  user  communications. 

3.  The  DoD  Session  Layer  incorporates  some  of  the  access  control,  account¬ 
ing,  and  authentication  functions  necessary  for  management  of  the  inter¬ 
network  system. 

This  approach  to  the  Session  Layer  seems  to  be  particularly  relevant  to  anti¬ 
cipated  DoD  applications.  The  placement  of  some  access  control  and  name  ser¬ 
vice  functions  within  the  layer  points  towards  future  DoD  standards  activity. 
In  addition,  the  enhanced  robustness  and  control  provided  bv  anticipated  ses¬ 
sion  layer  protocols  serve  some  of  DoD ' s  most  fundamental  requ i rements . 
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6.2  THE  JoO  SESSION  LAYER 
6.2.1  Purpose 

The  purpose  of  the  Session  Layer  is  to  provide  the  means  necessary  for 
cooperating  user-entities  to  organize  and  synchronize  their  data  exchanges. 
To  do  this,  protocols  within  the  Session  Layer  provide  services  allowing  the 
establishment  of  a  sess i on  among  user-entities,  and  to  support  their  orderly 
data  exchange  interactions.  Proper  management  of  session  establishment,  ses¬ 
sion  data  transfers,  and  session  termination  may  involve  the  coordinated 
action  of  various  session-entities,  both  on  behalf  of  the  participating  user- 
entities  and  on  behalf  o^  system  and  network  administrations. 

To  implement  the  transfer  of  data  between  the  user-entities,  a  session  uses 
the  services  of  the  Transport  Layer.  These  services  may  be  provided  by  a 
connection-oriented  or  by  a  connectionless  transport  protocol.  Even  when  the 
underlying  transport  service  used  for  data  transfers  is  connectionless,  it  may 
be  desirable  to  invoke  session-establishment  and  management  services  for  the 
purposes  of  name  resolution  or  access  control.  Transport  Layer  services  are 
used  to  support  the  exchanges  required  for  proper  management  of  the  session 
establishment  and  termination.  These  need  not  be  provided  by  the  same  tran¬ 
sport  protocol  which  is  used  for  transferring  user  data. 

Sessions  among  user  entities  are  created  when  requested  by  a  user-entity  at  a 
sess i on-serv i c e- access- poi nt .  During  the  lifetime  of  a  session,  session  ser¬ 
vices  are  used  by  the  user-entities  to  regulate  their  communication,  ensuring 
orderly  message  exchange  across  the  session.  The  session  exists  until 
released  by  the  user-entities,  unless  a  privileged  session-entity  participat¬ 
ing  in  the  overall  management  of  the  session  requests  the  session's  termina¬ 
tion.  Such  may  occur  in  situations  requiring  forced  session  termination 
either  for  precedence  or  security  considerations.  While  the  session  exists, 
session  services  maintain  the  state  of  the  session  even  over  data  loss  by  the 
Transport  Layer. 

A  session  may  be  initiated  by  a  user-entity,  and  may  be  joined  by  other  user- 
entities.  Session  establishment  may  involve  the  participation  of  several  spe¬ 
cialized  session-entities  in  order  to  provide  services  such  as: 

a.  name  to  session-address  mapping 

b.  determination  of  predefined  session  attributes 

c.  session  authorization  and  access ' contro 1 

d.  session  accounting 

e.  coordination  of  multi-user  sessions. 

Such  spec i a  I i zed.  sess i on-ent i t i es  may  act  on  behalf  of  system  and  network 
adm i n i s tr at i ons . 
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User-entities  may  establish  sessions  by  specifying  a  the  intended  session's 
attributes.  Such  attributes  may  include  transport-addresses  of  intended  par¬ 
ticipants,  access  control  requirements,  specification  of  redundant  entities, 
and  required  transport-connections.  Modification  rights  to  some  session-type 
attributes  may  be  restricted  to  certain  authorized  system  or  network  adminis¬ 
tration  entities. 

o-2-2  Services  Provided 

6.2.2. 1  Attribute  Definition 

Protocols  within  the  Session  Layer  may  provide  a  session  attribute  definition 
service,  which  enables  user-entities  to  define  the  attributes  of  a  session 
type.  These  attributes  determine  actions  to  be  taken  by  session-entities  in 
the  management  of  a  session  of  the  given  type.  Such  attributes  may  include 
the  f o I  lowing: 

a.  access  restrictions 

b.  necessary  user-entity  session  participation  (e.g.  for  monitoring  or 
accounting  purposes) 

c.  transport  services  required  for  support  of  the  session 

The  entity  attribute  definition  service  enables  user-entities  to  make  their 
own  attributes  known  to  the  session-entities.  Such  attributes  may  include  the 
fol lowing: 

a.  user-titles  (allowing  the  Session  Layer  to  determine  "name/address"  bind¬ 
ings) 

b.  availability  for  remotely  initiated  sessions 

c.  redundancy  of  role  with  other  user-entities  (e.g.  back-ups)  within  par¬ 
ticular  session  types. 

Declaration  of  session  type  attributes  and  entity  attributes  may  •  be  indepen¬ 
dent  of  any  particular  session  establishment.  Some  user-entities  may  be 
priviliged  to  manipulate  attributes  of  other  user-entities. 

6. 2. 2. 2  Session  Establishment 

Session  establishment  services  enable  user  entities  to  establish  a  session 
among  themselves. 

The  session  establishment  service  allows  the  user-entities  cooperatively  to 
determine  the  values  of  session  attributes  at  the  time  the  session  is  esta¬ 
blished.  The  session  establishment  request  may  also  reference  a  predefined 
set  of  session  attributes  (identified  by  a  sess i on-type- i dent i f i er)  . 

The  session  establishment  service  provides  to  the  user-entities  a  session- 
identifier  which  uniquely  specifies  the  session  within  the  environment  of  the 
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participating  session-entities.  This  identifier  may  be  used  by  the  user- 
entities  to  refer  to  the  session  during  the  lifetime  of  the  session. 

6. 2. 2. 3  Session  Termination 

The  sess i on- termi nat i on  service  allows  the  user-entities  to  release  a  session 
in  an  orderly  way  without  any  loss  of  data.  In  addition,  a  session  may  be 
terminated  by  a  specialized  session-entity  participating  in  the  overall 

management  of  the  session.  Such  a  specialized  session-entity  may  be  acting  on 

behalf  of  system  or  network  adm i n i s tra t i ons .  Participating  session-entities 
may  be  informed  of  the  reason  for  session  termination. 

6.2.2.U  Session  Abort 

The  session  abort  service  informs  the  user-entities  of  session  aborts.  A  ses¬ 
sion  may  be  aborted  due  to  unrecoverab ) e  errors  at  the  Transport  Layer,  or 
upon  demand  by  a  specialized  session-entity  par t i c i pat i ng  in  the  overall 

management  of  the  session.  Such  a  specialized  session-entity  may  be  acting  on 

behalf  of  system  or  network  administrations. 


6. 2. 2. 5 


of  service  negotiation 


Prior  to  the  establishment  of  each  session,  the  cor respondent  user-entities 
and  their  associated  session-entities  must  agree  on  the  quality  of  service  tc 
be  provided  over  each  session.  This  is  achieved  through  the  negotiation  of 
session  quality  of  service  parameters. 

The  following  parameters  affecting  the  session  establishment,  data  transfer, 
and  termination  phases  can  be  negotiated: 

Establishment  Phase 

-  establishment  delay 

-  security  classification 


precedence 


Oata  Transfer  Phase 


-  bit  reliability 

-  delivery  reliability 

-  sequence  reliability 


-  absolute  delay 


-  delay  variance 


reliability  versus  delay" 


I 
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Termination  Phase 

-  reliability  of  termination 

-  termination  delay 

Since  the  Session  Layer  is  not  primarily  responsible  for  maintaining  the  end- 
to-end  quality  of  service  for  data  transfers,  these  quality  of  service  parame¬ 
ters  for  the  most  part  are  passed  down  to  the  Transport  Layer  for  interpreta- 
t  i  on . 

Protocols  that  provide  reliable  stream,  real-time  stream,  and  transaction 
classes  of  service  are  anticipated  to  be  important  service  offerings  of  the 
Transport  Layer.  Consequently  these  same  services  are  available  to  the  users 
of  the  Session  Layer  for  their  data  transfers.  A  session  protocol  may,  how¬ 
ever,  provide  some  enhancement  even  during  the  data  transfer  phase.  For  exam¬ 
ple,  "real-time"  sess i on- 1 ayer  services  would  provide  some  assurances  of  delay 
and  delay  variance  minimization,  corresponding  to  the  transport  service  which 
is  used.  If  serious  problems  within  the  Transport  Layer  or  below  lead  to  the 
disconnection  of  a  transport-connection  supporting  a  real-time  session,  the 
session  protocol  could  take  steps  to  immediately  establish  a  new  transport- 
connection. 


6. 2. 2. 6  Normal  data  exchange 

The  normal  data  exchange  service  allows  a  sending  user-entity  to  transfer  a 
unit  of  data  to  a  receiving  user-entity. 


6. 2. 2. 7  Exception  reportinc 


The  exception  reporting  service  permits  the  user-entities  to  be  notified  ^ r 
unanticipated  situations  not  covered  by  other  services,  such  as  unrecoverable 
session  malfunctions. 


Session  attributes  as  determined  during  the  session's  establishment  may 
require  that  the  session-entities  take  special  action  upon  occurrence  of 
soecified  exception  conditions  such  as  failure  of  a  session  or  of  an  entity. 
Such  actions  may  include  notification  of  designated  user-entities  and  estab¬ 
lishment  of  new  transport-connections  (e.g.  to  a  designated  "back-up"  entity). 

6,2.3  Functions  within  the  Session  Laver 

The  functions  within  the  Session  Layer  are  those  wnich  must  be  performec  by  a 
session-entities  in  order  to  provide  the  services  required  of  a  specific  ses- 
s i on  protoco 1 . 

6. 2. 3-1  Session  establishment  and  control  functions 

A  protocol  within  the  Session  Layer  may  include  functions  which  allow  user- 
entities  to  define  and  modify  session  and  entity  attributes.  These  attributes 
could  be  used  to  determine  how  sessions  of  a  particular  type  are  to  be 
managed . 
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Maintenance  of  this  attribute  information  may  be  the  responsibility  of  spe¬ 
cialized  session-entities,  (e.g.  name  servers  or  access  controllers).  Such 
specialized  session-entities  may  be  involved  during  the  establishment  of  a 
session.  Other  specialized  session-entities  may  be  required  to  participate  in 
the  management  of  a  session  during  its  lifetime.  Transport  services  will  be 
used  for  information  exchanges  between  these  session-entities. 

6.2. 3- 2  Normal  data  exchange 

Session  protocols  do  not  substantially  add  value  to  the  normal  data  exchange 
services  provided  by  the  transport  protocols.  In  fact,  once  the  appropriate 
transport  service  has  been  decided  upon  to  support  a  given  session,  it  may  De 
that  session  entities  no  longer  play  a  role,  having  existed  primarily  to  help 
establish  the  required  transport  service  on  behalf  of  the  users.  With  such  a 
session  service,  the  users  would  use  transport  services  directly  upon  estab- 
1 i shment  of  the  session. 

6. 2. 3- 3  Session  recovery 

In  the  event  of  reported  failure  of  an  underlying  transpor t-connec t i on ,  a  ses¬ 
sion  protocol  may  contain  the  necessary  functions  to  regain  a  transport- 
connection  to  support  the  session,  which  continues  to  exist.  The  session- 
entities  involved  would  notify  the  user -ent i t i es  via  the  exception  reporting 
service  that  service  is  interrupted  and  would  restore  the  service  only  as 
directed  by  the  user-entities.  This  permits  the  user-entities  to  resynchron¬ 
ize  and  continue  from  an  agreed  state. 

Alternatively,  the  session-entities  may  take  restorative  action  without  inter¬ 
vention  from  the  user-entities.  In  this  case  the  user-entities  would  be  noti¬ 
fied  that  such  an  event  has  occurred. 

Restorative  actions  may  include  establishment  of  transpor t-connec t i ons  to 
designated  entities.  Session  attributes  (as  determined  at  the  time  of 
session-establishment)  can  indicate  what  actions  should  be  taken  by  the 
session-entities  in  response  to  specified  exception  conditions. 

6.2.3- 14  Session  Termination 

A  protocol  within  the  Session  Layer  contains  the  necessary  functions  to 
release  the  sessio-  in  an  orderly  way,  without  loss  of  data,  upon  request  by 
the  user-entities.  e  Session  Layer  also  contains  the  necessary  functions  to 
aoort  the  session  with  the  possible  loss  of  data. 
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6 . 3  Current  DoD  Session  Protocols 

At  present,  t here  are  no  DoD  stanaard  protocols  which  explicitly  conform  to 
the  proposed  DoD  Session  Layer.  A  variety  of  access  control  ano  authentica¬ 
tion  protocols  have  been  developed;  the  i ncompat i b i i i tes  among  these  protocols 
points  to  the  necessity  for  future  standardization  activity  in  this  area. 

The  Internet  Name  Server  Protocol  [7]  is  in  many  respects  an  example  of  a  ses¬ 
sion  protocol  as  described  in  the  DoD  Model,  particularly  in  its  extended  form 
(allowing  TCP  and  UDP  ports  to  be  assigned  to  names).  Companion  protocols 
(yet  undefined)  allowing  the  registration  of  names  within  the  name  database 
would  also  be  examples  of  session  protocols. 

Teleconferencing,  multi-media  services,  distributed  Database  access,  and  crit¬ 
ical  data  collection  processes  may  all  require  the  coherent  management  of  mul¬ 
tiple  entities,  perhaps  through  multiple  connections  established  in  coi.'.ert 
with  appropriate  session  protocols.  These  DoD  applications  are  not  well 
enough  defined  at  present  to  allow  for  the  identification  of  session  services 
which  mignt  be  desired. 
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The  Transport  Layer  incorporates  end-to-end  functions  which  enhance  the  data 
transfer  services  provided  by  the  Internet  Layer. 


Relatively  minor  differences  exist  between  the  DoD  and  ISO  Transport  Layer. 
One  difference  is  the  enhanced  emphasis  on  connectionless  as  well  as 
connection-oriented  services.  For  example,  UDP  is  a  perfectly  legitimate 
transport  protocol. 


Another  difference  lies  in  the  wording  of  the  quality  of  service  references. 
The  DoD  Transport  Layer  must  offer  a  flexible  range  of  services,  supporting 
bulk  transfer  applications  such  as  file  transfers,  delay-sensitive  applica¬ 
tions  (e.g.  voice),  and  transactions.  Although  the  ISO  model  intends  to  sup¬ 
port  such  a  variety  of  services,  the  Transport  Layer  is  heavily  connection- 
oriented,  with  an  inadequate  discussion  of  quality  of  service  negotiable 
parameters  (for  example,  delay  variation  is  not  included). 


The  following  paragraphs  briefly  describe  the  differences  between  the  DoD  and 
ISO  Transport  Layers. 


References  to  the  lower  layer  service  reflect  the  DoD  Internet  'ayer’s  connec¬ 
tionless  orientation. 


ISO's  discussion  of  quality  of  service  parameters  has  been  replaced.  Specific 
parameters  are  identified,  which  are  closely  matched  with  the  parameters  nego¬ 
tiable  across  the  other  layer  interfaces  (e.g.  between  the  transport  and  net¬ 
work  entities).  These  parameters  are  intended  to  be  sufficient  to  allow  iden¬ 
tification  of  a  broad  set  of  service  classes  which  are  required  to  support  DoD 
applications.  These  include  delay-sensitive  and  reliable  transaction  ser- 
v i ces . 


Graceful  closes  have  been  explicitly  introduced  as  an  important  service  which 
can  be  requested  for  a  tranport  connection.  According  to  the  negotiated  ter¬ 
mination  quality  of  service,  data  delivery  during  the  termination  phase  may  or 
may  not  be  guaranteed  -  the  termination  is  "graceful"  if  delivery  is 
guaranteed.  This  can  be  viewed  as  part  of  the  general  quality  of  service 
structure. 
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7.2  THE  DoD  TRANSPORT  LAYER 
7.2.1  Purpose 

Protocols  within  the  transport  layer  provide  transparent  transfer  of  data 
between  transport  addresses.  Transport  Layer  protocols  relieve  the  transport 
users  from  any  concern  with  the  detailed  way  in  which  cost  effective  transfer 
of  data  meeting  the  users’  service  requirements  is  achieved. 

The  transport  users  are  identified  to  the  Transport  Layer  by  transport- 
service-access-point  addresses  ("transport-addresses");  the  data  transfer  ser¬ 
vice  is  provided  to  the  addressable  entities  without  regard  to  their  location. 
Transport-addresses  are  drawn  from  a  large  enough  address  space  to  ensure  that 
many  users  within  a  single  host  may  be  distinguished.  Transport  protocols  are 
commonly  referred  to  as  "process-to-process"  protocols,  as  opposed  to  internet 
or  network  level  protocols  which  will  typically  allow  addressing  of  indiviaual 
hosts  but  not  of  large  numbers  of  users  within  hosts. 

Different  protocols  within  the  Transport  Layer  provide  different  services. 
For  example,  these  different  services  may  include  reliably  sequenced  transfers 
over  transport-connections,  unacknowledged  datagram  transfers,  and  delay- 
minimized  stream  transfers  for  "real-time"  applications.  Each  protocol  may 
also  allow  additional  quality  of  service  parameters  (specific  to  that 
protocol's  service)  to  be  negotiated  between  the  user -ent i t i es  and  the 
transport-enti ties. 

The  transport-servi ce  is  provided  by  the  Transport  Layer  performing  all  neces¬ 
sary  functions  in  conjunction  with  the  utilization  of  the  most  appropriate 
underlying  facilities  and  quality  of  service  available  from  'the  protocols 
within  the  Internet  Layer. 

The  Transport  Layer  is  required  to  optimise  the  use  of  the  available  communi¬ 
cations  resources  to  provide  the  performance  and  level  of  security  required  by 
each  communicating  transport  user  at  minimum  cost.  This  optimisation  will  be 
achieved  within  the  constraints  imposed  by  considering  the  global  demands  of 
all  concurrent  transport  users  and  the  overall  limit  of  resources  available  to 
the  Transport  Layer. 

Since  the  :nternet  service  provides  transport  of  data  units  from  one 
t r anspor t -ent i ty  to  another,  including  the  case  of  using  multiple  networks, 
and  relieves  the  Transport  Layer  of  any  concern  with  switching,  routing,  and 
relaying,  all  protocols  defined  in  the  Transport  Layer  will  have  end-to-end 
significance,  where  the  ends  are  defined  as  the  correspondent  transport- 
entities  which  may  reside  in  hosts  attached  to  different  networks. 

Transport  functions  resident  in  the  Transport  Layer  allow  the  Internet  Layer 
to  use  more  than  one  communication  resource  (e.g.  the  transfer  of  data  units 
by  the  Internet  Layer  may  involve  the  use  of  a  public  packet  switched  network, 
used  in  tandem  with  a  circuit  switched  network). 

The  transport  functions  invoked  in  a  transport  protocol  to  provide  a  requested 
service  quality  may  depend  on  the  quality  of  the  i nternet-serv i ce . 
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7.2.2  Services  Provided 

7.2.2. 1  General 

A  protocol  within  the 'Transpor t  Layer  uniquely  identifies  each  of  its  users  by 
its  transport-address .  Users  of  a  transport  protocol  are  provided  with  the  1 

means  to  request  the  transfer  of  data  between  two  transport-addresses  with 
specified  delay,  reliability,  security,  and  other  requirements.  The  user  of  1 

the  Transport  Layer  must  determine  which  transport  protocol  is  best,  able  to 
provide  the  desired  service. 

Some  transport  protocols  may  require  the  establishment  of  a  transport- 
connection  to  provide  their  service.  Such  connections  have  a  connection- 
establishment  phase,  data  transfer  phase,  and  connect ion-termi nat i on  phase. 

Quality  of  service  parameters  for  the  connection-establishment  phase,  data 
transfer  phase,  and  the  connec t i on- term i na t i on  phase  may  be  specified  by  the 
user . 

Other  transport  protocols  may  not  require  the  establishment  of  a  connection. 

Such  connectionless  services  could  be  provided  with  a  variety  of  reliability 
and  delay  quality  of  service  parameter  values. 

Connection-oriented  transport  protocols  may  allow  more  than  one  transport- 
connection  to  be  established  between  the  same  pair  of  transport-addresses;  the 
means  by  which  the  user  can  distinguish  between  the  transport-connection-end¬ 
points  will  be  provided  by  the  Transport  Layer,  in  terms  of  "transport- 
connect  i on-end-poi nt- i dent i f i ers" . 

The  existence  and  performance  of  each  transport-connection  is  independent  of 
all  other  .such  connections,  except  for  the  limitations  imposed  by  finite 
resources  available  to  the  transport  protocol  providing  the  service. 

7. 2. 2. 2  Establishment  services 

If  a  transport  protocol  provides  connection-oriented  service,  then  the  follow¬ 
ing  services  are  provided  by  the  transport  protocol  at  the  transpor t-serv i ce- 
access-poi nt: 

a)  Transport-connection  establishment 

Transport-connections  are  dynamically  established  to  a  peer  transport- 
address.  The  quality  of  service  of  the  transport-connection  may  be  nego¬ 
tiated  among  the  users  and  the  transport-service  via  various  parameter 
combinations  such  as  throughput,  transit  delay,  connection  set-up  delay 
and  various  guaranteed  values  of  parameters  affecting  the  connection 
establishment  phase,  data  transfer  phase,  and  connection  termination 
phase.  Such  quality  of  service  parameters  could  include: 

Connection  Establishment  Phase 

-  reliability  of  connection  establishment 
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-  connection  establishment  delay 

-  connection  security  classification 

-  connection  precedence/priority 
Data  Transfer  Phase 

-  bit  reliability 

-  delivery  reliability 

-  sequence  reliability 

-  absolute  delay 

-  delay  var i ance 

-  "reliability  versus  delay" 

Connection  Termination  Phase 

-  reliability  of  connection  termination 

-  connection  termination  delay 

A  connection-oriented  transport  protocol  will  allow  the  establishment  of 
transport-connection  only  when  both  peer  user-entities  of  the  given 
transport-connection  agree  on  the  quality  of  service  selected. 

7.2. 2-3  Data  transfer  services 

This  service  provides  data  transfer  in  accordance  with  the  agreed  upon  quality 
of  service.  When  this  quality  of  service  cannot  be  maintained  and  all  possi¬ 
ble  recovery  attempts  have  failed,  then  the  transport-connection  is  terminated 
and  the  transport  users  are  notified. 

a)  Transport-servi ce-da;a-uni t  transfer  provides  the  means  by  which  arbi¬ 
trarily  selected  transpor t-servi ce-data-un i ts  are  delimited  and  tran¬ 
sparently  transferred  in  sequence  from  one  sending  transport-service- 
access-point  over  a  transport-connection.  This  service  i-s  subject  to 
f 1 ow  con tro I . 

b)  Exped i ted-transport-servi ce-data-uni t  transfer  provides  an  additional 
means  of  information  exchange  on  a  transport-connection.  They  are  sub¬ 
ject  to  their  own  set  of  transpor t-serv i ce  and  flow  control  characteris¬ 
tics.  The  maximum  size  of  exped i ted- transpor t -serv i ce-da ta-un i ts  is  1  im- 
i  ted . 
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7. 2. 2. 4  Termination  services 

This  service  provides  the  means  by  which  either  session-entity  can  terminate 
the  connection  and  have  the  correspondent  session-entity  informed  of  the  ter¬ 
mination. 

According  to  the  negotiated  termination  duality  of  service,  data  delivery  dur¬ 
ing  the  termination  phase  may  or  may  not  be  guaranteed. 

7.2.3  Functions  within  the  layer 

7. 2. 3- 1  Genera)  overview 

The  functions  performed  by  a  protocol  within  the  Transport  Layer  may  include: 

1.  mapping  transpor t-addresses  onto  network-addresses ; 

2.  transfer  of  user  data  between  transport-addresses; 

3.  establishment  and  termination  of  transpor t-connect ions ; 

4.  end-to-end  sequence  control  on  individual  connections; 

5.  end-to-end  error  detection  and  any  necessary  monitoring  of  the  quality  of 
service; 

6.  end-to-end  error  recovery; 

7.  end-to-end  flow  control  on  individual  connections; 

8.  supervisory  functions 

9.  expedited  transpor t-serv i ce-data-un i t  transfer. 

Different  transport  protocols  will  include  different  functions  depending  on 
the  actual  transport  service  which  they  are  to  supply.  For  example,  a  connec¬ 
tionless  transport  protocol  will  not  include  the  connection-oriented  func- 
t i ons . 

The  following  sections  describe  the  types  of  functions  which  may  be  defined  in 
a  transport  protocol.  Only  the  first  is  required  for  a  connectionless  tran¬ 
spor  t  protoco I . 

7. 2. 3- 2  Address i nq 

When  a  transpor t-serv i ce  user  requests  that  data  be  transferred  from  one 
transpor t-serv i ce-access-00 i nt  to  another  (which  may  require  the  establishment 
of  a  transport-connection),  the  transport  entity  needs  to  determine  the 
internet-address  identifying  the  transport-entity  which  serves  that  correspon¬ 
dent  user-entity,  i.e.  which  maintains  that  correspondent  transport-address. 
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Because  the  transport-entities  support  services  on  an  end-to-end  basis  by 
means  of  end-to-end  functions,  no  intermediate  transport-entity  is  involved  as 
a  relay  between  the  end  transport-entities.  Therefore  the  internet-addresses 
on  which  the  transport  entity  maps  transport-addresses  are  those  identifying 
the  end  transport-entities. 

One  transport-entity  may  serve  more  than  one  user-entity.  Therefore  several 
transpor t-adoresses  may  be  associated  with  one  network-address  within  the  same 
transpor t-ent i ty .  Transport  protocols  include  sufficient  range  within  their 
space  of  transport-addresses  to  be  able  to  identify  many  users;  transport- 
addresses  are  typically  used  to  identify  processes  within  a  host. 

Corresponding  mapping  or  switching  functions  must  then  be  performed  within 
transport-entities  to  provide  these  facilities. 

7- 2. 3-3  Connection  Multiplexing 

Transport  connections  may  be  implemented  using  the  basic  connectionless  inter¬ 
net  service,  or  may  be  mapped  onto  internet-connections.  In  order  to  optimize 
the  use  of  internet-connections,  the  mapping  need  not  be  on  a  one-to-one 
basis.  A  cost  effectiveness  analysis  needs  therefore  to  be  made  in  each  par¬ 
ticular  implementation,  to  determine  whether  connection  multiplexing  needs  to 
be  performed  or  not. 

7. 2. 3-4  Phases  of  Connection  Operation 

for  connec t i on-or i ented  transport  service,  the  phases  of  operation  within  a 
transport  protocol  are  as  follows: 

a)  establishment  phase; 

b)  data  transfer  phase; 

c)  termination  phase. 


The  transfer  from  one  phase  of  operation  to  the  other  will  be  specified  in 
detail  within  the  protocol  for  the  Transport  Layer. 

7. 2. 3-5  Establishment  phase 


The  goal  of  the  es tab  I i shment  phase  is  to  establish  a  transpor t-connec 1 1  on 
between  the  two  transport  users.  The  functions  of  the  transport  protocol  dur¬ 
ing  this  phase  must  match  the  recuested  class  of  services  with  the  services 
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c)  establish  optimum  transport-protocol -data-un i t  size; 

d)  select  the  functions  that  will  be  operational  upon  entering  the  data 
transfer  phase; 

e)  map  transport-addresses  onto  internet-addresses; 

f)  provide  a  means  to  distinguish  between  different  transport  connections 
between  the  same  pair  of  tr ansoor t-serv i ce- access-po i n ts  (connection 
identification  function); 

g)  transportation  of  user  data. 

2. 3-6  Data  transfer  phase 

The  purpose  of  the  data  transfer  phase  is  to  transport  transport-service- 
data-units  between  the  two  tr anspor t-serv i ce-user s  connected  by  the 
t r anspor t-connec t i on .  This  purpose  is  achieved  by  means  of  transmission  of 
t ranspor t -protoco I  -  data-units  and  by  the  following  functions,  each  of  these 
being  used  or  not  used  in  accordance  with  the  result  of  the  class  of  service 
selection  performed  in  the  connection  establishment  phase. 

a)  blocking  is  a  function  used  to  collect  several  t- 3nspor t-serv i ce-data- 
units  into  a  single  transpor t-protoco I -data-un i t;  the  destination 
transport-entity  separates  the  blocked  transpor t-protoco 1 -data-un i ts ; 

b)  concatenation  is  a  function  used  to  collect  several  tr anspor t-protoco I  - 
data-units  into  a  single  network-servi ce-data-uni t;  the  destination 
transport-entity  separates  the  concatenated  transpor t-protoco! -data- 
un  i  ts ; 

c)  segmenting  is  a  function  used  to  split  a  single  transpor t-serv i ce-data- 
uni  t  into  multiple  transpor t-protoco 1 -data-un i ts ;  the  aestination 
transpor t-ent i ty  reassembles  the  segmented  transpor t -protoco I -da ta-un i ts ; 

d)  multiplexing  is  a  function  used  to  share  a  single  internet-connection 
used  between  two  or  more  transport-connections,  or  to  split  a  single 
tr anspor t-connec t i on  onto  multiple  i nterne t-connec t i ons ; 

e)  flow  control  is  a  function  used  to  regulate  the  flow  of  transport- 
protoco I -da ta-un i ts  between  two  transport-entities  on  one  transport- 
connec  t i on ; 

f)  error  detection  is  a  function  used  to  detect  the  loss,  corruption  dupli¬ 
cation,  (Disordering,  or  misdelivery  of  tr ansoor t-protoco 1 -da ta-un i t s ; 

g)  error  recovery  is  a  function  used  to  recover  from  detected  and  signalled 
errors ; 

h)  expedited  data  is  a  function  used  to  bypass  the  flov<  control  of  normal 
transpor t-protoco I -da ta-un i t ;  expedited  transport-protocol -data-uni t  flow 
is  controlled  by  its  own  flow  control; 
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i)  transpor t -serv i ce-data-un i t  delimiting  is  a  function  used  to  determine 
the  beginning  and  ending  of  a  transpor t-serv i ce-aa ta-un i t ; 

j)  transpor t-connec t i on  identification  is  a  function  to  unipuely  identify  a 
transpor t-connect i on  between  the  pair  of  transport-entities  supporting 
the  connection. 

7- 2. 3- 7  Termination  pnase 

The  purpose  of  the  termination  phase  is  to  terminate  the  transport-connection 
and  may  include  the  following  functions: 

a)  notification  of  reason  for  termination; 

t)  iaentificat  on  of  the  transport-connection  terminated; 

c)  possible  additional  information. 
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7 . 3  Current  OoO  Transport  Protocols 

At  present,  there  are  two  well-defined  DoD  Transport  Layer  protocols:  TCP  and 
UDP . 

The  service  offered  by  TCP  connections  is  directly  reflected  in  the  descrip¬ 
tion  of  " transpor t-connec t i ons" .  Modifications  to  the  ISO  Transport  Layer 
were  made  to  take  into  account  certain  services  offered  by  TCP  but  not 
included  within  OS  I  -  for  example,  graceful  closes.  UDP  fits  within  the  Model 
as  a  connectionless  transport  protocol. 

It  is  clear  that  additional  transport-level  services  will  be  required  by  OoD 
applications.  Real-time  connection  service  (offering  "guarantees"  on  delay 
and  delay  dispersion)  could  also  be  incorporated  within  the  Transport  Layer. 
Some  of  the  functions  performed  by  NVP  [10]  may  be  properly  included  within  a 
more  general-purpose  real-time  transport  protocol. 
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8.  THE  INTERNET  LAYER 

8 . 1  Differences  between  DoD  and  ISO  Internet  Layer 

The  Internet  Laye-  relieves  the  higher  layers  from  any  concern  with  how  data 
is  routed,  allowing  the  Transport  Layer  protocols  to  be  "end-to-end". 

There  are  many  different  approaches  to  internet  and  intranet  routing.  One 
approach  -  typified  by  DARPA  IP  and  the  Xerox  Pup  [10]  architecture  -  is  to 
transfer  universal  internet  datagrams  across  the  various  subnetworks  by  using 
each  subnetwork's  individual  internal  routing  scheme  between  gateways.  Thus 
internet  routing  is  datagram-based,  but  each  of  the  subnetworks  can  have  con¬ 
nectionless  or  connec t i on-or i ented  intranetwork  routing  independent  of  the 
interneTting  architecture. 

Alternatively,  internetwork  routing  can  be  based  on  connections.  Such  an 
approach  is  typified  by  X.75.  in  which  an  internet  connection  is  formed  by 
concatenating  several  intranetwork  X.25  connections  between  gateways. 

It  seems  clear  that  any  genera!  internetting  strategy  must  be  capable  of  work¬ 
ing  with  a  wide  variety  of  separate  intranet  routing  mechanisms.  Networks 
offering  connection-oriented  network  service  will  certainly  exist  (e.g.  X.25 
public  nets).  But  datagram  networks  will  also  be  very  preva-lent,  and  in  fact 
will  probably  come  to  predominate  as  local  area  networks  (which  are  for  the 
most  part  datagram  nets)  proliferate. 

There  is  no  ISO  Internet  Layer.  The  internetting  function  was  intended  to  be 
provided  through  network -connec t i ons  traversing  "tandem  subnetworks".  This  is 
similar  to  the  connection-concatenation  approach  of  X.75*  For  the  reasons 
stated  in  Section  3  of  this  Reference  Model  document,  DoD  requires  a  different 
approach . 

The  basic  approach  to  internetting  taken  within  the  DoD  Internet  Layer  is  con¬ 
nectionless  -  the  paradigm  being  IP.  However,  connection-oriented  internet 
protocols  are  not  precluded  by  the  model;  these  may  be  required  for  the  provi¬ 
sion  of  internet  services  for  delay-sensitive  applications  such  as  voice. 
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8.2  THE  DoD  INTERNET  LAYER 
8.2.1  Purpose 

The  Internet  layer  manages  transfers  of  data  units  on  behalf  of  users  who  may 
not  be  attached  to  a  common  network.  Users  of  the  internet-service  are 
relieved  from  all  concerns  regarding  the  topology  of  the  collection  of  net¬ 
works  and  gateways  which  together  form  the  Internet. 

The  Internet  Layer  includes  separate  protocols  which  may  provide  different 
types  of  service.  The  basic  service  is  a  connectionless  internet  service  In 
which  i nternet-serv i ce-data-un i ts  are  independently  transferred  between 
i nternet-serv i ce-access-po i nts .  Other  internet  protocols  may  provide  an 
internet  service  which  requires  the  establishment  of  internet-connections. 
Such  protocols  may,  for  example,  provide  a  service  which  minimizes  delay  vari¬ 
ations  between  separate  data  unit  transfers. 


The  Internet  Layer  provides  to  its  user  entities  independence  from  routing  and 
switching  considerations  associated  with  the  transfer  of  i nternet-serv i ce- 
data-units  across  multiple  networks.  It  makes  invisible  to  transport-entities 
how  the  Internet  Layer  uses  the  services  of  individual  networks  to  provide  the 
internet  service. 


In  other  words,  the  users  of  the 
For  example,  protocols  within 
systems.  Any  relay  functions  of 
vice  between  the  end-systems 
Layer . 


Internet  Layer  may  be  eno-system  oriented, 
the  Transport  Layer  operate  only  between  end- 
protocols  used  to  support  the  internet  ser- 
are  transparent  to  the  users  of  the  Internet 


8.2.2  Services  Provided 


8.2.2. 1  Genera  I 


The  basic  service  of  the  Internet  Layer  is  to  provide 
of  all  data  submitted  by  the  users.  This  service 
detailed  content  of  submitted  data  to  be  determined 
above  the  Internet  Layer. 


the  transparent  transfer 
allows  the  structure  and 
exclusively  by  layers 


All  services  are  provided  at  a  known  cost. 

The  Internet  Layer  contains  functions  necessary  to  provide  the  Transport  Layer 
with  a  firm  I nternet/Transport  boundary  which  is  independent  of  the  underlying 
networks  in  all  things  other  than  quality  of  service.  Thus  the  Internet  Layer 
is  assumed  to  contain  functions  necessary  to  mask  the  differences  in  the 
characteristics  of  different  transmission  and  network  technologies  into  a  con¬ 
sistent  internet  service. 


When  user  entities  request  service  from  a  connection-oriented  protocol  within 
the  Internet  Layer,  the  service  provided  at  each  end  of  an  internet  connection 
shall  be  the  same  even  in  the  case  of  a  internet-connection  spanning  several 
networks  where  each  of  the  networks  offers  dissimilar  services. 
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The  Internet  Layer  includes  protocols  providing  a  variety  of  types  of  service. 
Three  basic  types  of  service  hav.e  been  identified  which  require  separate 
internet  protocols: 

1.  Connectionless  internet  service 

2.  Reliable  sequenced  internet  service 

3.  Real-time  internet  service 

Reliable  sequenced  service  and  real-time  service  may  require  the  establishment 
of  internet-connections  between  the  internet-service-access-points. 

Users  of  a  particular  internet-protocol's  service  may  negotiate  additional 
quality  of  service  parameters  to  be  used  in  the  internet  transfers  on  their 
beha  1  f . 

In  the  case  of  connection  service,  the  quality  of  service  parameters  are  esta¬ 
blished  for  each  internet-connection.  While  this  quality  of  service  may  vary 
from  one  internet-connection  to  another  it  will  be  agreed  for  a  given 
internet-connection  and  the  same  at  both  internet-connection  endpoints. 

8. 2. 2. 2  I nternet-Addresses 

Users  of  the  internet  service  may  be  identified  by  means  of  internet-addresses 
(i .e.  internet-service-access-point  addresses).  Internet-addresses  are  pro¬ 
vided  by  the  Internet  Layer  and  can  be  used  by  user-entities  to  uniquely  iden¬ 
tify  other  user-entities,  i.e.  internet-addresses  are  the  means  by  which 
user-entities  can  communicate  using  the  i nternet-servi ce. 

This  may  be  independent  of  the  addressing  needed  by  the  underlying  networks. 

8. 2. 2. 3  Internet-Service-Oata-Unit  Transfer 

The  Internet  Layer  provides  for  the  exchange  of  i nternet-serv i ce-data-un i ts 
between  internet-addresses.  These  units  have  a  distinct  beginning  and  end  and 
the  integrity  of  the  unit  content  is  maintained  by  the  Internet  Layer.  The 
i nternet-serv i ce-data-un i ts  are  transferred  transparently  between  user- 
ent i t i es . 

The  service  offered  by  a  connectionless  protocol  within  the  Internet  Layer 
provides  no  guarantees  of  i nternet-serv i ce-da ta-un i t  delivery  to  the  intended 
i nternet-address ,  nor  is  the  received  sequence  of  i nternet-serv i ce-data-un i ts 
guaranteed  to  be  in  the  same  order  as  the  transmitted  sequence.  In  addition, 
i nternet-serv i ce-data-un i ts  may  be  duplicated  within  the  internet. 

3. 2. 2.1*  I  n  ter  ne  t-Connec  t  i  ons 


If  an  enhanced  level  of  i n ternet -serv i ce  (beyond  the  basic 
vice)  is  desired,  it  may  be  necessary  to  establish  a 
between  the  i nternet-serv i ce-access -po i nts ,  using  the 
connection-oriented  internet  protocol.  Different  such 


connectionless  ser- 
i n ter  net -connect i on 
services  of  a 
connection-oriented 
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internet  protocols  may  exist  to  provide  different  internet  services. 

A  internet-connection  is  the  means  of  transferring  data  between  user-entities 
when  reliably  sequenced  transfers  or  real-time  service  is  desired.  Protocols 
within  the  Internet  Layer  provide  the  means  to  establish,  maintain  and  ter¬ 
minate  internet-connections. 

More  than  one  internet-connection  may  exist  between  the  same  pair  of 
i nt erne t -addresses . 

8. 2. 2. 5  I nternet-Connec t i on-£ndooi nt- I  dent i f i ers 

Connection-oriented  internet  protocols  provide  to  their  users  an  internet- 
connect  i  on-endpo  i  nt-  i  dent  i  f  i  er  which  identifies  the  internet-connection- 
endpoint  uniquely  with  the  associated  i nternet-address . 

8. 2. 2. 6  Quality  of  Service  Parameters 

Internet  Layer  protocols  offer  a  variety  of  classes  of  service  the  user  enti¬ 
ties.  User-entities  attached  to  a  internet-service-access-point  can  further 
negotiate  additional  quality  of  service  parameters  with  the  associated 
internet-entity,  or  request  to  override  the  default  parameters  associated  with 
that  class  of  service. 

Data  transfers  provided  by  a  connectionless  internet  protocol  may  also  be 
governed  by  user-se I ectab 1 e  quality  of  service  parameters  on  each  internet- 
service-access-unit.  These  parameters  may  include: 

-  level  of  bit  reliability 

-  level  of  delivery  reliability 

-  delay 

-  secur i ty  1  eve  1 

Such  parameters  would  be  used  by  the  Internet  Layer  entities  during  the  rout¬ 
ing  process  (to  determine,  for  example,  which  of  several  possible  networks  to 
choose) . 

Internet-service-access-units  are  delivered  to  the  destination  user-entity 
intact  (though  with  possible  bit  corruptions  commensurate  with  the  desired 
level  of  bit  reliability).  Any  fragmentation  of  the  internet-service-access- 
unit  which  may  have  occured  within  the  Internet  Layer  is  hidden  from  the 
user-ent i t i es . 


Similarly,  internet-connections  are  governed  by  quality  of 
negotiated  between  the  user-entities  and  the  internet-ent 
Layer  establishes  and  maintainr  a  selected  quality  of  serv 
of  the  connection. 


service  parameters 
ties.  The  Internet 
ce  for  the  duration 
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The  quality  of  service  parameters  include: 

a)  Residual  errors  which  may  arise  from  alteration,  loss,  duplication, 
disoraering,  misdelivery  of  i n ter ne t-serv i ce-da ta-un i ts ,  or  others; 

d)  service  availability  which  is  the  probability  that  a  requested  internet- 
connection  can  be  established. 

c)  reliability,  which  is  the  mean  time  between  failures  and  mean  time  to 
repair  an  estabished  internet-connection; 

d)  throughput,  which  is  the  information  transfer  capacity; 

e)  transit  delay,  which  includes  vacations  on  the  transit  delay; 

f)  delay  for  i nternet-connect i on  establishment. 

Different  internet  protocols  will  offer  different  standard  combinations  of 
these  quality  of  service  parameters  to  provide,  for  example,  reliable 
sequenced  network  service  or  real-time  network  service. 

8. 2. 2. 7  E r ror  Notification 

Unrecoverable  er-ors  detected  by  the  Internet  Layer  will  be  reported  to  the 
user-ent i ties. 

Error  notification  may  or  may  not  lead  to  the  termination  of  a  internet- 
connection.  according  to  the  specification  of  a  particular  internet  service. 

8. 2. 2. 8  Seouenc i nc 

The  Internet  Layer  may  provide  the  service  of  sequenced  delivery  of  internet- 
serv i ce-data-un i ts  over  a  given  internet-connection  when  requested  by  the 
user-ent i t i e* . 

8. 2. 2. 9  Flow  Control 

A  user  entity  which  is  receiving  at  one  end  of  a  internet-connection  can  cause 
the  internet-service  to  stop  transferring  i nternet-serv 1 ce-data-un 1 ts  over  the 
internet-service-access-point.  This  flow  control  condition  may  or  may  not  be 
propagated  to  the  other  end  of  the  i n terne t  -connec t i on  and  thus  be  reflected 
to  the  transmitting  user-entity,  according  to  the  specification  of  a  particu¬ 
lar  internet  service. 

8.2.2.10  Conges  t ; on  Con t -c 1 

The  Internet  Layer  provides  the  service  of  congestion  control,  which  ensures 
that  total  network  resources  are  maintained  ;n  a  non-saturated  state.  This 
internet  service  attempts  to  avoid  serious  service  degradations  caused  oy 
extreme  Quantities  of  offered  traffic.  The  Invocation  of  congestion  control 
within  the  internet  Layer  may  result  in  the  internet-service  Stooping  the 
transfer  of  i nter net -serv i ce-da ta-un i ts  over  the  interface  between  the 
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Transpor.  and  Internet  layers. 

8.2.2.11  Termination  Services 

A  user  of  a  connection-oriented  internet  service  may  request  termination  of  a 
internet-connection.  The  internet-service  may  not  guarantee  the  delivery  of 
data  preceding  the  termination  request  and  still  in  transit,  according  to  the 
spec i f i cat i on  of  the  specific  i nternet-serv i ce .  The  internet-connection  will 
be  terminated  regardless  of  the  action  taken  by  the  correspondent  transport 
ent i ty . 

8,2.3  functions  within  the  Internet  Layer 
8 . 2 . 3 • 1  Genera  1 

The  functions  to  be  provided  within  the  Internet  Layer  are  outlined  below. 

8. 2. 3*2  Address i nq 

Each  internet-entity  is  uniquely  identified  within  the  scope  of  a  single  net¬ 
work  by  its  network-address,  i.e.  the  address  of  the  network-service-access- 
point  to  which  the  internet-entity  is  attached.  Such  a  network-address  will 
be  in  the  particular  format  defined  for  the  particular  network. 

To  uniquely  identify  an  i nternet-ent i ty  within  the  scope  of  the  entire  inter¬ 
net  it  is  necessary  to  define  ne twork- i dent i f i er s .  A  network- i dent i f i er 
uniquely  names  a  particular  network  within  the  internet.  The  internet  is  in 
fact  the  collection  of  networks  which  have  been  granted  a  network- i dent i f i er 
by  the  internet  administration.  Each  internet-entity  can  then  be  uniquely 
identified  within  the  internet  via  the  combination  of  a  network- i dent i f i er  and 
a  network-address  (in  the  format  of  the  particular  network). 

A  universal  format  for  network-addresses  within  the  internet  can  be  defined. 
If  a  particular  network  uses  a  network-address  format  which  is  not  compatible 
with  the  universal  format,  then  the  internet-entities  attached  to  that  network 
must  then  be  responsible  for  mapping  between  network-addresses  in  the  univer¬ 
sal  format  and  those  in  the  network's  own  particular  format. 

8 . 2 . 3 • 3  Rout i nq 

Routing  is  performed  to  select  the  aopropriate  route  between  internet- 
addresses,  and  for  transferring  i nternet-protoco I -data-un i ts  between  them. 

Routing  functions  may  involve  intermediate  nodes,  acting  as  relays  between  end 
i nternet-ent i t i es .  Such  intermediate  nodes  are  called  internet-gateways. 
Internet-entities  are  responsible  for  determining  if  the  transfer  of 
i nternet-protoco 1 -da ta-un i ts  requires  that  they  be  routed  through  an 
internet-gateway,  and  for  choosing  which  i nternet-gateway .  This  involves 
determining  the  network-address  of  the  appropriate  internet-gateway,  and  then 
using  the  service  of  the  network  layer  to  effect  the  transfer. 
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8.2.3-1*  Fragmentation  and  Reassembly 


Internet-entities  attached  to  a  given  network  are  responsible  for  ensuring 
that  i nternet-protocol -data-un i ts  submitted  to  the  network  for  transmission 
are  not  larger  than  the  maximum  ‘si2e  ne twork -serv i ce-da ta-un i t  for  that  net¬ 
work.  Within  an  internet-gateway,  this  may  involve  fragmentation  of  a 
.received  i nternet-protocol -data-uni t  into  smaller  i nternet-protocol -data-un i ts 
prior  to  routing  through  another  network.  Internet-entities  are  responsible 
far  ensuring  that  such  fragmentation  is  transoarent  to  the  users  of  the  inter¬ 
net  service. 

8. 2. 3-5  I  n ter net -connect  ions 


This  function  includes  mechanisms  for  providing  internet-connections  between 
transport-ent i ties. 

Since  the  basic  service  of  the  Internet  Layer  is  provided  by  a  connectionless 
protocol,  the  use  of  an  internet-connection  will  only  be  required  if  a  quality 
of  service  not  obtainable  from  the  connectionless  service  is  required.  For 
example,  to  minimize  delay  variations  it  may  be  necessary  to  route  internet- 
protoco 1 -data-un i ts  through  a  fixed  sequence  of  gateways  which  have  reserved 
resources  for  the  internet-connection.  Such  functions  would  be  the  responsi¬ 
bility  of  the  appropriate  connection-oriented  internet  protocol. 

Internet-connections  may  require  the  use  of  network-connections. 

8. 2. 3- o  Error  detection 

Error  detection  functions  are  used  to  check  that  the  quality  of  service  pro¬ 
vided  at  a  internet-service-access  point  is  maintained.  Error  detection  in 
the  Internet  Layer  uses  error  notification  from  the  Network  Layer.  Additional 
error  detection  capab i 1 i t i es  'm i gh t  be  necessary  to  provide  the  required  qual- 
i ty  of  serv i ce . 

8. 2. 3- 7  Error  recovery 

This  function  includes  mechanisms  for  recovering  detected  errors.  Depending 
on  the  quality  of  the  network  service  provided,  these  functions  may  vary. 

8. 2. 3. 8  Sequenc i nq 

This  function  includes  mechanisms  for  providing  the  service  of  sequenced 
delivery  of  i nternet-servi ce-data-un i ts  over  a  given  internet-connection  when 
requested  by  transpor t-ent i t i es . 

8. 2. 3-  9  Flow  control 


This  function  includes  mechanisms  for  providing  the  service  of  flow  control  of 
i nternet-servi ce-data-uni ts  over  a  given  internet-connection  when  requested  by 
transpor  t-ent i ties. 
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8.2-3*10  Congestion  Control 

This  function  includes  mechanisms  for  protecting  the  internet  system  from  ser¬ 
vice  degradations  due  to  extreme  quantities  of  offered  traffic. 
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8 . 3  Current  DoD  Internet  Protocols 

The  primary  protocol  within  the  Internet  Layer  is  IP.  This  is  a  connection¬ 
less  protocol  which  proviaes  a  fragmentation  and  reassembly  service  as 
described  in  the  Model.  Most  DoO  applications  will  use  IP  for  internet 
transfers . 

IP  includes  within  its  mechanisms  a  means  by  which  error  reports  and  other 
control  messages  may  be  exchanged.  These  mechanisms  use  the  services  of  IP, 
and  are  specified  separately  from  IP  as  the  "Internet  Control  Message  Proto¬ 
col".  However,  ICMP  is  not  a  "user"  of  IP  in  the  sense  that  TCP  is  a  user, 
rather  it  is  in  fact  an  integral  part  of  IP  itself. 

Another  protocol  associated  with  the  Internet  system  is  the  "Gateway  Gateway 
Protocol"  (GGP)  .  Although  in  many  respects  this  protocol  may  be  viewed  as  a 
Transport  Protocol,  we  prefer  to  describe  it  as  belonging  to  the  Internet 
Layer.  The  reason  for  this  classification  is  that  GGP  plays  an  important  role 
in  the  overall  provision  of  internet  service  to  users.  It  certainly  does  not 
fit  the  "process  addressability,  end-to-end  service"  model  of  a  transport  pro¬ 
tocol.  GGP  is  a  good  example  of  why  the  DoD  Reference  Model  takes  a  much  less 
restrictive  view  of  the  layer  concept  than  does  the  ISO  Model;  protocols  such 
as  GGP  are  very  difficult  to  fit  within  a  strict  layer. 

One  final  DoO  internet  protocol  which  should  be  mentioned  is  the  "Stream  Pro¬ 
tocol"  (ST  [11]).  This  protocol  provides  internet  data  transfers  for  delay- 
sensitive  applications.  Resources  within  gateways  are  reserved  on  a  "per- 
connection"  basis  to  ensure  that  delay  variances  are  minimized  between 
separate  transfers.  This  experimental  protocol  is  intended  to  support  appli¬ 
cations  such  as  packet  voice,  and  is  a  good  example  of  a  connection-oriented 
i  nternet  protoco I  . 
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9.  THE  NETWORK  LAYER 

9 • 1  Differences  between  OoO  and  ISO  Network  Laver 

The  Network  Layer  describes  the  services  which  are  typically  provided  by  a 
single  network  within  the  Internet. 

The  ISO  Network  Layer  is  heavily  oriented  towards  the  concept  of  the 
"network-connection".  The  use  of  the  phrase  "tandem  subnetworks"  is  typical 
of  ISO's  cohnect i on-or i entat ion  even  for  internet  routing.  It  seems  the  model 
for  Network  Layer  services  assumed  by  ISO  is  the  connection-oriented  X . 2 5 
interface  offered  by  public  packet-switched  networks. 

The  DoO  Reference  Mode!  takes  a  more  general  view  of  the  Network  Layer  by 
recognizing  connectionless  Network  services.  As  local  networks  proliferate 
within  the  DoO  environment,  it  is  likely  that  networks  offering  connectionless 
services  will  in  fact  predominate.  Since  DoO's  internetting  approach  assumes 
only  connectionless  service  from  the  constituent  networks,  and  since  some  DoO 
higher  level  protocols  are  themselves  connectionless,  the  provision  of  connec¬ 
tionless  network  service  is  to  be  encouraged  within  the  DoD  Model. 

Thus  the  basic  differences  between  the  DoD  and  ISO  Network  Layers  are  as  fol- 
1  ows : 

1.  The  DoD  Network  Layer  allows  (indeed  encourages)  connectionless  service, 
whereas  the  ISO  layer  is  very  connection-oriented. 

2.  All  internetting  aspects  of  the  OoO  Model  are  placed  within  the  DoO 
Internet  Layer;  this  is  issue  is  confused  within  the  ISO  Model,  with  some 
saying  it  is  present  in  the  current  Network  Layer,  others  saying  it 
requires  a  separation  of  the  Network  Layer  into  "sublayers". 
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9.2  THE  OoD  NETWORK  LAYER 

9.2.1  Purpose 

The  Network  Layer  provides  the  functional  means  to  exchange  network-serv i ce- 
data-units  between  internet-entities.  Such  exchanges  use  the  services  of  an 
individual  network  within  the  internet.  Thus  network- 1 ayer  protocols  are  not 
responsible  for  routing  of  data  units  between  different  networks  within  the 
i nternet . 

Internet  entities  may  be  able  to  use  various  different  network  protocols  to 
transfer  data  across  a  given  network.  One  network  protocol  may  provide  a  con¬ 
nectionless  network  service  in  which  network-serv i ce-data-un i ts  are  indepen¬ 
dently  transferred  between  ne twork-serv i ce-access-po i nts .  A  different  proto¬ 
col  may  provide  for  the  establishment  of  network-connections,  which  may  be 
used  by  the  internet-entities. 

A  specific  network  may  not  offer  multiple  types  of  service  to  its  attached 
internet-entities.  For  example,  a  network  may  only  provioe  a  connectionless 
service,  or  may  only  provide  a  connection-oriented  service.  The  fact  that  not 
all  networks  offer  a  connection-oriented  service  is  one  reason  why  the  connec¬ 
tionless  internet-service  is  taken  to  be  the  basic  internet-service,  since 
connection-oriented  services  can  easily  support  connectionless  services,  but 
not  vice  versa. 

All  networks  in  the  internet  must  provide  a  connectionless  network  service  to 
the  Internet  Layer.  It  is  not  required  that  all  networks  in  the  internet  pro¬ 
vide  connection-oriented  network  service. 

The  Network  Layer  provides  to  the  internet-entities  independence  from  routing 
and  switching  considerations  associated  with  the  transfer  of  network-servi ce- 
data-units  across  a  single  network.  It  makes  invisible  to  internet-entities 
how  the  Network  Layer  uses  underlying  resources  such  as  data- 1 i nk-connect i ons 
to  provide  the  network-serv i ce .  Routing  among  multiple  networks  is  the 
responsibility  of  the  Internet  Layer. 

9.2.2  Services  provided  to  the  internet  Layer 
9-2.2.  1  Genera  1 

The  basic  service  of  the  Network  Layer  is  to  provide  the  transparent  transfer 
of  all  data  submitted  by  the  Internet  Layer.  This  service  allows  the  struc¬ 
ture  and  detailed  content  of  submitted  data  to  be  determined  exclusively  by 
layers  above  the  Network  Layer. 

All  services  are  provided  to  the  Internet  Layer  at  a  known  cost. 

Three  basic  types  of  service  provided  by  protocols  within  the  Network  Layer 
have  been  identified: 


1.  Connectionless  network  service 
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2.  Reliable  sequenced  network  service 

3.  Real-time  network  service 

These  different  services  may  be  provided  by  different  protocols. 

All  networks  are  required  to  provide  a  connectionless  network  service.  Reli¬ 
able  sequenced  service  and  real-time  service  may  require  the  establishment  of 
network-connections  between  the  network-service-access-points. 

in  the  case  of  connection  service,  the  quality  of  service  parameters  are  esta¬ 
blished  for  each  network-connection.  While  this  quality  of  serv.ice  may  vary 
from  one  network-connection  to  another  it  will  be  agreed  for  a  given  network- 
connection  and  the  same  at  both  network-connection  endpoints. 

9. 2. 2. 2  Network -Addresses 

Internet-entities  are  known  to  the  Network  Layer  by  means  of  network-addresses 
( i  .  e .  network-service-access-point  addresses).  Network-addresses  are  provided 
by  the  Network  Layer  and  can  be  used  by  i nternet-ent i t i es  to  uniquely  identify 
other  internet-entities,  i .e.  network-addresses  are  the  means  by  which 
internet-entities  can  communicate  using  the  network-service.  The  Network 
Layer  uniquely  identifies  each  of  end  systems  (represented  by  internet- 
entities)  by  their  network-addresses. 

9.2. 2. 3  Network-Serv i ce-Data-Un i t  Transfer 


The  Network  Layer  provides  for  the  exchange  of  network-serv i ce-data-un i ts 
between  network-addresses.  These  units  have  a  distinct  beginning  and  end  and 
the  integrity  of  the  unit  content  is  maintained  by  the  Network  Layer. 

The  network-serv i ce-data-un i ts  are  transferred  transparent  1 y  between 
i nternet-ent i t i es . 

9.2.2.L  Network -Connect i ons 

If  an  enhanced  level  of  network-servi ce  is  desired,  it  may  be  necessary  to 
establish  a  network-connection  between  the  network-serv i ce-access-poi nts . 
Such  a  service  may  be  provided  by  a  connection-oriented  protocol  within  the 
Network  Layer.  For  example,  a  network-connection  may  be  the  -means  of 
transferring  data  between  internet-entities  when  reliably  sequenced  transfers 
or  real-time  service  is  desired.  A  connection-oriented  protocol  within  the 
Network  Layer  provides  the  means  to  establish,  maintain  and  terminate 
network-connect i ons . 

More  than  one  network-connection  may  exist  between  the  same  pair  of  network- 
addresses.  Only  specific  network-service-access-points  offer  connection  ser- 
v i ces . 
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9- 2. 2. 5  Network -Connect i on-£ ndpo i nt- 1  dent i f i er s 

At  those  network-service-access-points  which  offer  network-connection  ser¬ 
vices,  the  Network  Layer  provides  to  the  i nternet-ent i ty  a  network- 
connect  i on-endpo i nt- i dent i f i er  which  identifies  the  ne twor k-connec t i on- 
endpoint  uniquely  with  the  associated  network-address . 

9.2. 2. 6  Quality  of  Service  Parameters 

Protocols  within  the  Network  Layer  may  offer  a  variety  of  classes  of  network 
service  to  the  internet-entities.  Internet-entities  attached  to  a  network- 
servi ce-access-poi nt  can  further  negotiate  additional  quality  of  service 
parameters  with  the  associated  networx-ent i ty ,  or  request  to  override  the 
default  parameters  associated  with  that  class  of  service. 


A  connectionless  protocol  within  the  Network  Layer  may  provide  user-selectable 
quality  of  service  parameters  on  each  network-serv i ce-access -un i t .  These 
parameters  may  include: 

-  level  of  bit  reliability 

-  level  of  delivery  reliability 


-  delay 

-  secur i ty  level 

Such  parameters  would  be  used  by  the  Network  Layer  during  the  routing  process 
(to  determine,  for  example,  which  of  several  possible  data  links  to  choose). 


Network-service-access-units  are  delivered  to  the  destination  internet-entity 
intact  (though  with  possible  bit  corruptions  commensurate  with  the  desired 
level  of  bit  reliability).  Any  fragmentation  of  the  network-service-access- 
unit  which  may  have  occured  within  the  Network  Layer  is  hidden  from  the 
i nternet-ent i ties. 


If  a  network  provides  a  connection-oriented  service,  each  network-connection 
is  governed  by  quality  of  service  parameters  negotiated  between  the  internet- 
entities  and  the  network-entities.  The  Network  Layer  protocol  establishes  and 
maintains  a  selected  quality  of  service  for  the  duration  of  the  connection. 

The  quality  of  service  parameters  include: 


a)  Residual  errors  which  may  arise  from  alteration,  loss,  duplication, 
disordering,  misdelivery  of  network-serv i ce-data-un i ts ,  or  others; 

b)  service  availability  which  is  the  probability  that  a  requested  network- 
connection  can  be  established. 

c)  reliability,  which  is  the  mean  time  between  failures  and  mean  time 
repair  an  estabished  network-connection; 


to 
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d)  throughput,  which  is  the  information  transfer  capacity; 

e)  transit  delay,  which  includes  variations  on  the  transit  delay; 

f)  delay  for  network-connection  establishment. 

9. 2. 2. 7  Error  Notification 

Uncoverable  errors  detected  by  the  Network  Layer  protocols  may  be  reported  to 
the  internet-entities. 

Error  notification  may  or  may  not  lead  to  the  termination  of  a  network- 
connection,  according  to  the  specification  of  a  particular  network  service. 

9. 2. 2. 8  Seauenc i nq 

The  Network  Layer  may  provide  the  service  of  sequenced  delivery  of  network- 
serv i ce-data-un i ts  over  a  given  network-connection  when  requested  by  the 
i nternet-ent i t i es . 

9.2. 2. 9  F low  Control 

A  internet-entity  which  is  receiving  at  one  end  of  a  network-connection  can 
cause  the  network-service  to  stop  transferring  network-serv i ce-data-un i ts  over 
the  service  interface  between  the  internet  and  Network  Layers.  This  flow  con¬ 
trol  condition  may  or  may  not  be  propagated  to  the  other  end  of  the  network- 
connection  and  thus  be  reflected  to  the  transmitting  internet-entity,  accord¬ 
ing  to  the  specification  of  a  particular  network  service. 

9.2.2.10  Congestion  Control 

The  Network  Layer  provides  the  service  of  congestion  control,  which  ensures 
that  total  network  resources  are  maintained  in  a  non-saturated  state.  This 
network  service  attempts  to  avoid  serious  service  degradations  caused  by 
extreme  quantities  of  offered  traffic.  The  invocation  of  congestion  control 
within  the  Network  Layer  may  result  in  the  network-service  stopping  the 
transfer  of  network-serv i ce-data-un i ts  over  the  interface  between  the  Internet 
and  Network  Layers. 

9.2.2.11  Termination  Services 

A  internet-entity  may  request  termination  of  a  network-connection.  The 
network-service  may  not  guarantee  the  delivery  of  data  preceding  the  termina¬ 
tion  request  and  still  in  transit,  according  to  the  specification  of  the 
specific  network-serv i ce .  The  network-connection  will  be  terminated  regard¬ 
less  of  the  action  taken  by  the  correspondent  internet  entity. 
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9.2.3  functions  within  the  Network  Laver 
9.2.3. 1  Genera i 


The  functions  which  may  be  provided  a 
Only  the  first  is  a  function  which  is 
toco  I s . 


Networ  k 
requ i red 


Layer  protocol  are  outlined, 
for  connectionless  network  pro- 


9.2.  3-2  Rout i no  and  swi tch i nq 


Routing  and  switching  are  performed 
between  network-addresses,  and  for 
between  them. 


for  selecting  the  appropriate  route 
transferring  network -serv ice-data-uni ts 


Routing  and  switching  functions  may  involve  intermediate  nodes,  acting  as 
relays  between  end  network-entities. 


In  a  data  network,  an  intermediate  node  is  a  point  where  one  or  more  network- 
entities  may  interconnect  data  circuits  at  the  Physical  Layer  and  data  links 
at  the  Data  Link  Layer. 


The  service  offered  to  internet-entities  over  a  network-service-access  point 
allows  transfer  of  network-serv i ce-data-un i ts  to  other  network-service- 
access-points.  Such  transfers  may  involve  switching  entities  within  the  net¬ 
work  . 

9. 2. 3-3  Network-Connection  Establishment 

A  connection-oriented  protocol  within  the  Network  Layer  includes  mechanisms 
for  establishing  network-connections  between  internet-entities.  This  may 
include  negotiation  of  quality  of  service  parameters  which  are  to  govern  the 
established  network  connection. 

9. 2. 3. A  Hultiplexi nq 

In  order  to  optimize  the  use  of  data- 1 i nk-connect i ons ,  the  Network  Layer  may 
multiplex  network-connec t i ons  onto  data- I i nk-connect i ons . 


9. 2. 3-5  Error  detection 

Error  detection  functions  are  used  to  check  that  the  quality  of  service  pro¬ 
vided  at  a  network-servi ce-access  point  is  maintained.  Error  detection  in  the 
Network  Layer  uses  error  notification  from  the  Data  Link  Layer.  Aaditiona! 
error  detection  capabilities  might  be  necessary  to  provide  the  required  qual- 
i ty  of  serv i ce . 

9. 2. 3. 6  Error  recovery 

This  function  includes  mechanisms  for  recovering  detected  errors.  Depending 
on  the  quality  of  the  network  service  provided,  these  functions  may  vary. 
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9. 2. 3- 7  Seguenc i no 

This  function  includes  mechanisms  for  providing  the  service  of  sequenced 
delivery  of  ne twork-serv , ce-da ta-un i ts  over  a  given  network-connect  ion  when 
requested  by  internet-entities. 

9. 2. 3- 8  flow  control 

This  function  includes  mechanisms  for  providing  the  service  of  flow  control  of 
network-serv i ce-data-un i ts  over  a  given  network-connection  when  requesteO  by 
i nternet-ent i ties. 
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9 . 3  Current  DoD  Network  Layer  Protocols 


The  large  number  of  different  DoD  networks,  and  their  wide 
and  purpose,  necessitates  a  DoD  Network  Layer  capable  of 
intra-network  routing  schemes.  tn  this  section  we  discuss 
posed  DoD  intranetwork  protocols  as  they  relate  to  the  DoD 


variation  in  design 
supporting  multiple 
present  and  pro- 
Network  Layer. 


The  primary  DoD  internetting  strategy  is  embodied  in  the  Internet  Protocol. 
IP  is  a  datagram  internetting  scheme  whereby  internet  datagrams  are  routed 
among  hosts  and  gateways  using  the  local  subnetwork's  internal  routing  mechan¬ 
isms.  The  requirements  of  IP  thus  clearly  yield  the  model  for  the  "basic" 
connec t i on  1  ess  service  as  described  in  the  DoD  Network  Layer.  IP  sits  in  the 
Internet  Layer,  and  would  call  on  the  services  of  the  protocols  within  the 
Network  Layer  for  routing  within  a  subnetwork.  All  protocols  within  the 
internet  Layer's  use  the  services  of  the  protocols  within  the  Network  Layer 
for  intranetwork  routing. 


Examples  of  such  Network  Layer  protocols  include: 
-  "Host/mP"  with  1822 


-  X.25 

-  various  local  area  network  broadcast  routing  schemes 

-  connection-establishment  control  mechanisms  within  circuit-switched  net¬ 
works 


Note  that  the  DoD  model's  Network  Layer  does  not  preclude  any  combination  of 
Internet  protocol  and  Network  protocol  for  a  specific  data  transfer.  For 
example,  an  IP  module  could  use  an  X.25  virtual  circuit  to  exchange  datagrams 
with  another  IP  module.  However,  some  combinations  are  certainly  more  useful 
than  others,  and  a  user's  quality  of  service  requests  to  the  Network  Layer 
will  affect  the  choice  of  network  mechanisms. 
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10.  THE  DATA  LINK  LAYER 

10.1  Differences  between  the  OoO  and  ISO  Data  Link  Layers 

The  ISO  Data  Link  Layer  allows  network-entities  to  communicate  via  "data- 
link-connections",  which  are  built  using  physical  circuits  provided  by  the 
Physical  Layer.  The  primary  purpose  of  the  Data  Link  Layer  is  to  detect  and 
possibly  recover  from  errors  introduced  at  the  Physical  Layer.  Depending  on 
the  requested  quality  of  service,  the  data- 1 i nk-connect i on  may  additionally 
perform  sequence  and  flow  control  functions. 

The  ISO  Data  Link  Layer  does  not  take  into  consideration  the  type  of  service 
offered  in  many  contemporary  systems  built  using  a  broadcast  medium  (e.g. 
coaxial  cable  or  radio).  In  these  systems,  there  is  little  notion  of  “connec¬ 
tion"  at  the  link  level.  Instead,  "frames"  are  transferred  between  data- 
link-entities  in  a  connectionless  (and  unreliable)  fashion.  Error  detection 
is  generally  performed  at  the  link  level,  but  often  there  is  no  attempt  at 
sequence  control  or  error  recovery  -  such  mechanisms  are  left  up  to  the  higher 
1 ayers . 

The  DoO  Data  Link  Layer  differs  from  the  ISO  Data  Link  Layer  primarily  in  the 
addition  of  connectionless  transport.  Quality  of  service  parameters  can  be 
requested  for  such  transfers,  with  the  recognition  that  some  quality  of  ser¬ 
vice  requests  can  only  be  satisfied  through  the  establishment  of  a  data-! ink- 
connection. 
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10.2  THE  DoD  da~a  link  layer 

10.2.  1  Pur  pose 

The  Data  Link  Layer  proviaes  functional  and  proceaural  means  to  exchange 
data- 1 i nk-serv i ce-data-un i ts  among  user -ent i t i es .  Such  exchanges  may  involve 
the  establishment  of  a  data- 1 i nk-connect i on  between  the  user-entities.  The 
data-link  service  uses  one  or  several  phys i ca 1 -connect i ons . 

The  objective  of  this  layer  is  to  detect  and  possibly  correct  errors  wnich  may 
occur  in  the  Physical  Layer.  This  may  be  achieved  using  either  connection- 
oriented  or  connectionless  protocols  within  the  Data  Link  Layer. 

10.2.2  Services  Provided 

10.2.2.1  Data  transfer 

The  Data  Link  Layer  provides  a  service  which  allows  a  user-entity  to  transfer 
da ta- 1 i nk -serv i ce-data-un i ts  to  another  user-entity.  Transfers  are  governed 
by  selectable  quality  of  service  parameters  including  bit  reliability, 
delivery  reliability,  sequence  reliability,  delay  and  delay  variation. 

The  basic  mode  of  data  transfer  is  connectionless.  However,  the  provision  of 
certain  combinations  of  quality  of  service  parameters  may  require  the  estab¬ 
lishment  of  a  data-link  connection. 

If  connectionless  transfers  are  provided  by  a  data  link  protocol,  the  ability 
to  transfer  a  single  data  unit  to  multiple  user-entities  may  also  be  sup¬ 
ported  . 

The  size  of  the  da ta- 1 i nk-serv i ce-data-un i ts  may  be  limited  by  the  relation¬ 
ship  between  he  phys i ca 1 -connec t i on  error  rate  and  the  Data  Link  Layer  error 
detection  capability. 

10.2.2.2  Data-i ink-connection 

The  Data  Link  Layer  may  provide  one  or  more  data- 1 i nk-connect i ons  between  two 
user-entities.  A  data- 1 i nk-connect ion  is  always  activated  and  deactivated 
dynamically.  A  data- I i nk-connect ion  is  always  built  over  one  or  several  pairs 
of  physical -connec t i on-endpo i n ts . 

10.2.2.3  Data-i ink-connection-end po int-ide r,  ti^iers 

The  Data  Link  Layer  provides  da ta- 1 i nk-connect i on-endpo i nt- i dent i f i ers  that 
can  be  used  by  a  user-entity  to  identify  another  user-entity;  for  example, 
when  data- 1 i nk-connect i ons  are  built  upon  multipoint  physical  connections. 

10.2.2.1*  Sequenc  i  nc 


When  required,  the  sequence  integrity  of  da ta- 1 i nk-serv i ce-da ta-un i ts  will  be 
ma i nta i ned . 
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10.2.2- 5  Error  notification 

Notification  is  provided  to  the  user-entity  when  any  unrecoverable  error  is 
detected  by  the  Data  Link  Layer. 

10.2.2.6  f 1 ow  contro 1 

Each  user-entity  can  dynamically  control  (up  to  the  agreed  maximum)  the  rate 
at  which  it  receives  data-1 ink-servi ce-data-uni ts  from  a  data- 1 i nk-connect i on . 
This  control  may  be  reflected  in  the  rate  at  which  the  Data  Link  Layer  will 
accept  data- 1 i nk-serv i ce-data-un i ts  at  the  correspondent  data-1 ink- 
connect  i on-endpo i nt . 

10.2.2.7  Quality  of  service  parameters 

Quality  of  service  parameters  may  be  optionally  selectable.  For  connection- 
oriented  service,  the  Data  Link  Layer  establishes  and  maintains  a  selected 
quality  of  service  for  the  duration  of  the  data- 1 i nk-connect i on .  The  quality 
of  service  parameters  include: 

a)  Mean  time  between  detected  but  unrecoverable  errors 

b)  Residual  error  rate,  where  errors  may  arise  from:  alteration,  loss, 
duplication,  disordering,  misdelivery  of  data- I i nk-serv i ce-data-un i ts , 
and  other  causes. 

« 

c)  Service  availability 

d)  Transi t  delay 

e)  Throughput,  which  is  the  information  transfer  capacity. 

Different  data- I i nk-servi ce-access-poi nts  may  provide  different  classes  of 
data- 1 i nk-servi ce,  where  a  service  class  is  a  predefined  range  of  values  for 
specific  quality  of  service  parameters. 

10.2.3  Functions  within  the  layer 

10.2.3- 1  Connectionless  Data  Transfers 

This  function  provides  for  the  transfer  of  data  units  between  user-entities 
without  requiring  the  establishment  of  a  data  link  connection. 

This  function  may  include  the  capability  of  transferring  a  data  unit  to  multi¬ 
ple  user-entities  via  a  single  transmission. 

10.2.3- 2  Data- 1 i nk-connect ion  activation  and  deactivation 

This  function  activates  and  deactivates  data- I i nk-connect i ons  on  existing 
activated  phys i ca 1 -connect i ons .  When  a  phys i ca I -connect i on  has  multiple  end¬ 
points  (e.g.  multipoint  connection),  a  specific  function  is  needed  within  the 
Data  Link  Layer  to  identify  the  da t a- 1 i nk-connec t i ons  using  such  a  physical- 
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connect i on . 

10.2.3- 3  Data- 1 ink-service-data-units  mapping 

This  function  maps  da ta- 1 i nk- serv i ce-da ta-un i ts  into  data- 1 i nk-protoco 1 -oata- 
units  on  a  one  to  one  basis. 

10.2. Da  ta- I i nk -connect i on  downward -mu  1 t i P 1  ex i no 

This  function  performs  downward-multiplexing  of  one  data- 1 i nk-connect i on  onto 
several  phys i ca I -connect i ons . 

10.2.3- 5  Delimiting  and  Synchronization 

These  functions  allow  the  recognition  of  the  sequence  of  bits  transmitted  over 
the  phys i ca 1 -connect i on  as  a  data- 1 i nk-protoco 1 -da ta-un i t . 

10.2.3- 6  Sequence  control 


This  function  maintains  the  sequential  order  of  data- 1 i nk-serv i ce-data-un i ts 
across  the  data- 1 i nk-connect i on ,  if  such  service  is  requested  by  the  user- 
entities. 

10.2.3- 7  Error  detection 

This  function  detects  transmission,  format  and  operational  errors  occurring 
either  on  the  phys i ca 1 -connect i on,  or  as  a  result  of  a  malfunction  of  the 
corresponaent  data- I i nk-ent i ty . 

10.2.3- 8  Error  recovery 

This  function-  attemDts  to  recover  detected  transmission,  format  and  opera¬ 
tional  errors  and  notifies  the  user-entities  of  those  which  are  unrecoverable. 

10.2.3- 9  t 1 ow  control 

This  function  permits  provision  of  the  flow  control  service. 

10.2.3- 10  Identification  and  parameter  exchange 

This  function  performs  data- 1 i nk-ent i ty  identification  and  parameter  exchange. 

10.2.3- 11  Conveying  data  circuit  control  to  the  Network  layer 

The  Data  Link  layer  conveys  to  the  network  layer  the  capability  to  request 
assembly  of  data  circuits  within  the  Physical  Layer  (i.e.  the  capability  of 
performing  control  of  circuit  switching). 

10.2.3- 12  Data  Link  Layer  Management 

The  Data  Link  layer  protocols  deal  with  some  management  activities  of  the 
layer  (such  as  activation  and  error  control). 
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10.3  Current  DoD  Data  Link  Protocols 

The  ISO  Data  Link  Layer  is  designed  to  incorporate  many  current  Data  Link 
protocols,  such  as  HDLC  and  AOCCP.  These  protocols  typically  have  various 
"modes  of  use"  which  are  compatible  with  the  ISO  data- 1 i nk-serv i ce  descrip¬ 
tion. 

As  an  extension  of  the  ISO  Oata  Link  Layer,  the  DoD  model  will  similarly  cover 
many  of  the  existing  data  link  protocols.  The  link  protocols  which  were  used 
as  the  model  during  the  development  of  the  ISO  architecture  are  all 
connection-oriented  -  i.e.  there  is  a  specific  link  establishment  phase,  fol¬ 
lowed  by  a  data  transfer  phase,  followed  by  a  link  disconnection  phase.  Data 
transfers  are  often  flow  controlled,  acknowledged  and  retransmitted,  allowing 
the  data  link  protocol  to  provide  a  reliable  stream  service  to  its  users.  The 
description  of  these  services  within  the  ISO  Data  Link  Layer  allow  HDLC, 
ADDCP,  Bisync,  and  other  standard  link  protocols  to  be  used  within  ISO  Open 
Systems . 

However,  the  proliferation  of  broadcast-media  local  area  networks  (e.g. 
cablebus  systems  such  as  Ethernet)  requires  that  enhancements  be  made  to  the 
ISO  Data  Link  Layer  to  cover  "connectionless"  datagram-oriented  link  proto¬ 
cols.  These  link  protocols  (with  no  flow  control  or  retransmission  mechan¬ 
isms)  can  be  incorporated  directly  into  the  DoD  model.  Many  of  these  connec¬ 
tionless  protocols  include  "broadcast"  and  "multicast"  services  as  described 
i n  the  mode  1  . 

It  is  anticipated  that  future  DoO  standardization  efforts  will  be  directed  at 
these  local  network  link-level  protocols. 
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